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Preface 


CMMI®  (Capability  Maturity  Model®  Integration)  is  a  collection  of  best 
practices  that  helps  organizations  improve  their  processes.  It  was 
initially  developed  by  a  product  team  from  Industry,  U.S.  government 
and  the  Software  Engineering  Institute  for  application  to  process 
improvement  in  the  development  of  products  and  services  covering  the 
entire  product  life  cycle  from  conceptualization  through  maintenance 
and  disposal.  Following  the  success  of  CMMI  models  for  development 
organizations,  the  need  was  identified  for  a  CMMI  model  addressing  the 
acquisition  environment.  This  need  was  reinforced  and  gained  further 
attention  due  to  similar  needs  expressed  by  General  Motors  (GM), 
which  acquires  information  technology  (IT)  solutions.  Aligned  with  GM’s 
strategy,  GM  projects  or  programs  develop  requirements  and  design 
constraints  and  oversee  multiple  suppliers  that  develop  IT  solutions  and 
then  deploy  the  resulting  products  and  services  into  one  or  more  of 
GM’s  business  units.  This  approach  parallels  the  acquisition  processes 
used  in  many  government  organizations. 

General  Motors,  in  collaboration  with  the  SEI  and  with  approval  of  the 
CMMI  Sponsors  and  Steering  Group,  sponsored  the  development  of  an 
initial  draft  CMMI  for  Acquisition  (CMMI-ACQ)  constellation,  which  will 
lead  to  a  CMMI-based  acquisition  model  formally  accepted  by  both 
government  and  industry  after  piloting  of  the  initial  draft  CMMI-ACQ  has 
been  completed.  This  draft  is  based  on  the  CMMI  Version  1.2 
architecture  and  framework  which  incorporates  the  concept  of 
constellations,  which  are  groupings  of  components  to  support  a  specific 
model  application  such  as  Development  (DEV)  or  Acquisition  (ACQ). 

The  Office  of  the  Secretary  of  Defense  (OSD)  has  recognized  the  value 
of  using  this  initial  draft  CMMI-ACQ  as  a  basis  for  piloting  and  further 
development  to  create  a  final  validated  acquisition  model  useful  to  both 
government  and  industry. 


Purpose 


This  document  presents  the  initial  draft  CMMI-ACQ,  which  adapts 
CMMI  for  acquisition  organizations.  The  initial  draft  CMMI-ACQ  is  a 
collection  of  best  practices  that  is  generated  from  the  CMMI  vl  .2 
Architecture  and  Framework  and  acquisition  best  practices  from 
government  and  industry. 
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The  CMMI  Architecture  and  Framework  supports  the  CMMI  Product 
Suite  by  allowing  multiple  models,  called  constellations,  and  training 
courses  to  be  generated  that  support  specific  areas  of  interest. 

The  initial  draft  CMMI-ACQ  is  based  on  the  CMMI  Model  Foundation 
(i.e.,  16  process  areas  that  cover  project  management,  organizational 
and  support  process  areas;  the  generic  goals  and  practices;  and 
glossary),  the  CMMI  Acquisition  Module,  and  the  prior  Software 
Acquisition  Capability  Maturity  Model  (SA-CMM).  It  also  incorporates 
attempts  by  several  acquisition  organizations  to  adapt  the  CMMI  for 
Development  (CMMI-DEV)  constellation  for  an  acquisition  organization. 

The  initial  draft  CMMI-ACQ  provides  guidance  for  the  application  of  the 
CMMI  framework  to  the  acquirer  or  acquisition  discipline.  The  practices 
focus  on  activities  required  for  supplier  sourcing,  initiating  and  awarding 
supplier  agreements  and  managing  acquisition  of  products  and  services 
through  a  set  of  standard  metrics,  acceptance  criteria,  and  supplier 
deliverables.  The  initial  draft  CMMI-ACQ  integrates  bodies  of 
knowledge  that  are  essential  for  an  acquirer.  Supplier  activities  are  not 
addressed  in  the  initial  draft  CMMI-ACQ. 

By  integrating  these  bodies  of  knowledge,  the  initial  draft  CMMI-ACQ 
provides  a  comprehensive  solution  for  acquirers  as  they  work  with 
suppliers  to  develop  and  maintain  products  and  services.  CMMI-DEV 
may  be  treated  as  a  reference  for  supplier  executed  activities  for 
systems  engineering,  software  development,  and  hardware  design  work 
in  an  acquisition  initiative. 


Acknowledgement 


Many  talented  people  were  involved  in  developing  the  initial  draft 
CMMI-ACQ:  the  primary  development  team,  the  review  participants, 
and  the  CMMI  Steering  Group. 

The  primary  development  team  wrote,  reviewed,  revised,  discussed, 
and  agreed  on  the  structure  and  technical  content  of  the  initial  draft 
CMMI-ACQ,  including  the  application  of  the  CMMI  architecture,  the 
framework,  and  models. 


ii 


Preface 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Review  teams  took  drafts  of  the  content  and  gave  substantive  feedback 
to  the  development  team,  which  was  then  incorporated  into  subsequent 
versions  of  the  draft.  This  feedback  came  from  their  knowledge  of  the 
CMMI  model  construct,  as  well  as  from  their  own  practical  experiences 
as  acquirers  or  suppliers.  Piloting  of  this  content  will  occur  in  2006,  and 
the  piloting  team  will  plan  and  manage  piloting  activities.  This  team  will 
identify  candidate  organizations  to  participate  in  piloting,  will  prepare 
pilot  materials,  help  with  training  activities,  and  consolidate  and 
summarize  pilot  results.  A  representative  sample  of  possible  audiences 
for  the  eventual  acquisition  model  will  be  selected  in  order  to  fully  test 
the  applicability  of  the  initial  draft  CMMI-ACQ. 

Members  of  these  groups,  who  were  involved  in  developing  the  initial 
draft  CMMI-ACQ,  are  listed  in  Appendix  C. 


Audience 


The  audience  for  the  initial  draft  CMMI-ACQ  includes  anyone  interested 
in  process  improvement  in  an  acquisition  environment.  Whether  you  are 
familiar  with  the  concept  of  Capability  Maturity  Models  or  whether  you 
are  seeking  information  to  get  started  on  your  improvement  efforts,  the 
initial  draft  CMMI-ACQ  will  be  useful  to  you.  This  document  is  also 
intended  for  people  who  want  to  use  it  for  an  appraisal.1 


Organization  of  This  Document 


The  document  is  organized  into  three  main  parts: 

•  Part  One — About  Adapting  CMMI  for  Acquisition  Organizations 

•  Part  Two — Generic  Goals  and  Practices,  and  the  Process  Areas 

•  Part  Three — The  Appendices  and  Glossary 

Part  One,  “About  Adapting  CMMI  for  Acquisition  Organizations,” 

consists  of  five  chapters: 

•  Chapter  1 ,  “Introduction,”  offers  a  broad  view  of  CMMI  and  the 
eventual  CMMI  for  Acquisition  constellation.  It  is  an  introduction  to 
the  concepts  of  process  improvement  and  describes  the  history  of 
models  used  for  process  improvement  and  different  process 
improvement  approaches. 

•  Chapter  2,  “Process  Area  Components,”  describes  all  of  the 
components  of  the  Adapting  CMMI  for  Acquisition  Organizations 
process  areas. 


1  An  appraisal  is  an  examination  of  one  or  more  processes  by  a  trained  team  of  professionals  using  a  reference 
model  (e.g.,  CMMI)  as  the  basis  for  determining  strengths  and  weaknesses. 
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•  Chapter  3,  “Tying  It  All  Together,”  assembles  the  model 
components  and  explains  the  concepts  of  maturity  level  and 
capability  level. 

•  Chapter  4,  “Using  CMMI  Models,”  describes  paths  to  adoption  and 
use  of  CMMI  (and  the  initial  draft  CMMI-ACQ)  for  process 
improvement  and  benchmarking. 

Part  Two,  “Generic  Goals  and  Practices,  and  the  Process  Areas,” 
contains  the  required  and  expected  components  for  the  potential 
acquisition  constellation.  It  also  contains  related  informative 
components,  including  subpractices,  notes,  and  typical  work  products. 

To  make  these  process  areas  easy  to  find,  they  are  organized 
alphabetically  by  process  area  acronym.  Each  section  contains 
descriptions  of  goals,  best  practices,  and  examples. 

Part  Three,  “Appendices,”  consists  of  the  following  sections: 

•  Appendix  A,  “References,”  provides  a  list  of  references  used  in 
development  of  the  document 

•  Appendix  B,  “Acronyms,”  defines  the  acronyms  used  in  this 
document. 

•  Appendix  C,  “Adapting  CMMI  for  Acquisition  Organizations  Project 
Participants” 

•  Appendix  D,  the  “Glossary”  defines  many  of  the  terms  used  in 
CMMI  and  in  this  document. 


How  to  Use  This  Document 


Whether  you  are  new  to  process  improvement,  new  to  CMMI,  or 
already  familiar  with  CMMI,  Part  One  can  help  you  understand  why  the 
initial  draft  CMMI-ACQ  is  the  guide  to  use  for  improving  your  acquisition 
processes. 

Readers  New  to  Process  Improvement 

If  you  are  new  to  process  improvement  or  new  to  the  CMM®  concept, 
we  suggest  that  you  read  chapter  1 ,  “Introduction,”  first.  Chapter  1  will 
give  you  an  overview  of  process  improvement  and  explain  what  CMMI 
is  all  about. 

Next,  skim  Part  Two,  including  generic  goals  and  practices  as  well  as 
specific  goals  and  practices,  to  get  a  feel  for  the  scope  of  the  best 
practices  contained  in  the  initial  draft  CMMI-ACQ.  Pay  close  attention  to 
the  purpose  and  introductory  notes  at  the  beginning  of  each  process 
area. 
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In  Part  Three,  look  through  the  references  in  Appendix  A  and  select 
additional  sources  you  think  would  be  beneficial  to  read  before  moving 
forward  with  using  the  initial  draft  CMMI-ACQ.  Read  through  the 
acronyms  and  glossary  to  become  familiar  with  the  language  of  CMMI. 
Then,  go  back  and  read  the  details  of  Part  Two. 

Readers  Experienced  with  Process  Improvement 


If  you  are  new  to  CMMI  but  have  experience  with  other  process- 
improvement  models,  such  as  the  Software  CMM  (version  1 .1 )  or  the 
Systems  Engineering  Capability  Model  (i.e.,  EIA  731),  you  will 
immediately  recognize  many  similarities  [SEI  1995,  EIA  1998], 

We  recommend  that  you  read  Part  One  to  understand  how  CMMI  is 
different  from  other  process-improvement  models,  but  you  may  want  to 
read  some  of  the  sections  more  quickly  than  others.  Read  Part  Two 
with  an  eye  open  for  best  practices  you  recognize  from  the  models  you 
have  already  tried.  Identifying  familiar  material  gives  you  a  feel  for  what 
is  new  and  what  has  been  carried  over  from  the  model  you  already 
know. 

Next,  review  the  glossary  to  understand  how  some  terminology  may 
differ  from  that  used  in  the  process-improvement  model  you  know. 
Many  concepts  will  be  repeated,  but  they  may  be  called  something 
different. 

Readers  Familiar  with  CMMI 

If  you  have  reviewed  or  used  a  CMMI  model  before,  you  will  quickly 
recognize  the  CMMI  concepts  discussed  and  the  best  practices 
presented. 


Additional  Information  and  Reader  Feedback 


You  can  find  additional  information  from  various  other  sources  about 
CMMI,  such  as  the  background  and  history  of  the  CMMI  models,  as  well 
as  the  benefits  of  using  CMMI  models.  Many  of  these  sources  are  listed 
in  Appendix  A  and  are  also  documented  on  the  CMMI  Web  site — 
http://www.sei.cmu.edu/cmmi/. 

Suggestions  for  improving  CMMI  are  welcome.  For  information  on  how 
to  provide  feedback,  see  the  CMMI  Web  site  at 
http://www.sei.cmu.edu/cmmi/models/change-requests.html  [SEI  2],  If 
you  have  questions  about  CMMI,  send  an  e-mail  to  cmmi- 
comments@sei.cmu.edu. 
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1  Introduction 


Now  more  than  ever,  organizations  are  increasingly  becoming 
acquirers2  of  technology  solutions  by  obtaining  development  and 
maintenance  services  from  suppliers,  and  developing  less  and  less 
technology  solutions  in-house.  The  intent  of  this  widely  adopted 
business  strategy  is  to  improve  an  organization’s  operational 
efficiencies  by  leveraging  a  supplier’s  capabilities  to  deliver  quality 
solutions  rapidly,  at  lower  cost,  with  the  most  appropriate  technology. 

[ACQ] 


Acquisition  of  technology  solutions  is  challenging  because  acquirers 
must  take  overall  accountability  for  solution  delivery,  while  allowing  the 
supplier  to  perform  the  tasks  necessary  to  develop  and  maintain  the 
solution,  [acq] 


According  to  Dun  and  Bradstreet3,  20  percent  to  25  percent  of  large 
information  technology  (IT)  acquisition  projects  fail  within  two  years  and 
50  percent  fail  within  five  years.  Mismanagement,  inability  to  articulate 
customer  needs,  poor  requirements  definition,  inadequate  vendor 
selection  and  contracting  processes,  insufficient  technology  selection 
procedures,  and  uncontrolled  requirements  changes  are  all  factors  that 
contribute  to  project  failure.  The  onus  for  these  disturbing  statistics  does 
not  sit  exclusively  with  the  supplier,  but  also  with  the  acquirer.  The 
majority  of  project  failures  could  be  avoided  if  organizations  learned 
how  to  properly  prepare  for,  engage  with,  and  manage  suppliers,  [acq] 

In  addition  to  the  challenges  cited  above,  an  overall  key  to  a  successful 
acquirer-supplier  relationship  is  communication,  [acq] 

Unfortunately,  many  organizations  have  not  invested  in  the  capabilities 
necessary  to  effectively  manage  projects  in  an  acquisition  environment. 
Too  often  acquirers  disengage  from  the  project  once  the  supplier  is 
hired  to  develop  the  technology  solution.  Too  late  they  discover  that  the 
project  is  not  on  schedule,  deadlines  will  not  be  met,  technology 
selected  is  not  viable,  and  the  project  has  failed,  [acq] 


2  In  the  initial  draft  CMMI-ACQ,  the  term  project  refers  to  the  acquisition  project;  the  term  organization  refers 
to  the  acquisition  organization;  the  term  acquirer  refers  to  acquisition  projects. 

3  Other  studies  have  reported  similar  findings,  e.g.,  Stronger  Management  Practices  are  needed  to  Improve 
DoD’s  Software  Intensive  Weapons  Acquisitions,  GAO-04-393  (March  2004). 
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The  acquirer  has  a  focused  set  of  major  objectives.  These  include  the 
requirement  to  maintain  a  relationship  with  the  business  to  fully 
comprehend  its  needs.  In  addition,  the  relationship  with  the  supplier 
through  the  supplier  agreement  and  the  acquirer’s  supplier 
management  activities  gives  the  acquirer  the  scope  and  execution 
direction  to  deliver  to  the  business.  The  acquirer  owns  the  project, 
executes  overall  project  management,  and  is  accountable  for  delivering 
solutions  to  the  business,  [acq] 

In  the  current  marketplace,  there  are  maturity  models,  standards, 
methodologies,  and  guidelines  that  can  help  an  organization  improve 
the  way  it  does  business.  However,  most  available  improvement 
approaches  focus  on  a  specific  part  of  the  business  and  do  not  take  a 
systemic  approach  to  the  problems  that  most  organizations  are  facing. 
By  focusing  on  improving  one  area  of  a  business,  these  models  have 
unfortunately  perpetuated  the  stovepipes  and  barriers  that  exist  in 
organizations. 

Capability  Maturity  Model®  Integration  (CMMI®)  provides  an  opportunity 
to  avoid  or  eliminate  these  stovepipes  and  barriers  through  integrated 
models  that  transcend  disciplines. 

This  document  provides  guidance  for  the  application  of  the  CMMI 
framework  to  the  acquirer  or  acquisition  discipline.4  [acq] 

The  initial  draft  CMMI  for  Acquisition  (CMMI-ACQ)  contains  16  “core” 
process  areas  that  cover  project  management,  process  management 
and  support  process  areas.  In  addition,  four  process  areas  outside  of 
these  core  process  areas  are  further  modified  or  adapted  to  the 
acquisition  discipline.  Two  acquisition  unique  process  areas  are  also 
included.  These  six  process  areas  address  unique  acquisition  practices 
addressing  solicitation  and  supplier  agreement  development, 
acquisitions  management,  acquisition  requirements  development, 
acquisitions  technical  solution,  acquisition  validation,  and  acquisition 
verification,  [acq] 

The  practices  in  all  process  areas  focus  on  activities  of  the  acquirer. 
Those  activities  include  supplier  sourcing,  developing  and  awarding 
contracts  (supplier  agreements),  and  managing  acquisition  of  solutions 
where  solutions  include  both  products  and  services.  Supplier  activities 
are  not  addressed  in  this  document.  For  suppliers,  CMMI  for 
Development  (CMMI-DEV)  may  be  treated  as  a  reference  model  for 
those  suppliers  developing  products  and  services,  [acq] 


4  The  terms  outsourcing  and  acquisition  as  disciplines  are  used  interchangeably  in  this  report. 
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The  initial  draft  CMMI-ACQ  will  be  reviewed  by  additional  government 
and  industry  stakeholders  and  be  used  in  pilot  appraisals  before  it  will 
be  submitted  to  the  CMMI  Steering  Group  for  final  approval.  The 
intended  use  of  the  initial  draft  CMMI-ACQ  is  to  provide  organizations 
with  a  resource  of  effective  and  proven  practices  to  support  acquisition 
process  improvement.  This  document  can  also  be  used  by  the  supplier 
community  to  better  understand  the  expectations  of  its  customers,  [acqj 


About  Capability  Maturity  Models 


The  SEI  has  found  several  dimensions  that  an  organization  can  focus 
on  to  improve  its  business.  Figure  1.1  illustrates  the  three  critical 
dimensions  that  organizations  typically  focus  on:  people,  procedures 
and  methods,  and  tools  and  equipment,  [acq] 


Procedures  and  methods 
defining  the  relationship  of 
tasks 


B 


People 
with  skills, 
training,  and 
motivation 

Figure  1.1:  The  Three  Critical  Dimensions 


Tools  and 
equipment 


But  what  holds  everything  together?  It  is  the  processes  used  in  your 
organization.  Processes  allow  you  to  align  the  way  you  do  business. 
They  allow  you  to  address  scalability  and  provide  a  way  to  incorporate 
knowledge  of  how  to  do  things  better.  Processes  allow  you  to  leverage 
your  resources  and  to  examine  business  trends. 

This  is  not  to  say  that  people  and  technology  are  not  important.  We  are 
living  in  a  world  where  technology  is  changing  by  an  order  of  magnitude 
every  ten  years.  Similarly,  people  typically  work  for  many  companies 
throughout  their  careers.  We  live  in  a  dynamic  world.  A  focus  on 
process  provides  the  infrastructure  necessary  to  deal  with  an  ever- 
changing  world,  and  to  maximize  the  productivity  of  personnel  and  the 
use  of  technology  to  be  more  competitive. 
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Manufacturing  has  long  recognized  the  importance  of  process 
effectiveness  and  efficiency.  Today,  many  organizations  in 
manufacturing  and  service  industries  recognize  the  importance  of 
quality  processes.  Process  helps  an  organization’s  workforce  meet 
business  objectives  by  helping  them  work  smarter,  not  harder,  and  with 
improved  consistency.  Effective  processes  also  provide  a  vehicle  for 
introducing  and  using  new  technology  in  a  way  that  best  meets  the 
business  objectives  of  the  organization. 

In  the  1930s,  Walter  Shewhart  began  work  in  process  improvement  with 
his  principles  of  statistical  quality  control  [Shewhart  1931],  These 
principles  were  refined  by  W.  Edwards  Deming  [Deming  1986]  and 
Joseph  Juran  [Juran  1988],  Watts  Humphrey,  Ron  Radice,  and  others 
extended  these  principles  even  further  and  began  applying  them  to 
software  in  their  work  at  IBM  and  the  SEI.  Humphrey’s  book  Managing 
the  Software  Process  [Humphrey  1989]  provides  a  description  of  the 
basic  principles  and  concepts  on  which  many  of  the  capability  maturity 
models  are  based. 

The  SEI  has  taken  the  process-management  premise,  “the  quality  of  a 
system  or  product  is  highly  influenced  by  the  quality  of  the  process  used 
to  develop  and  maintain  it,”  and  defined  capability  maturity  models  that 
embody  this  premise.  The  belief  in  this  premise  is  seen  worldwide  in 
quality  movements,  as  evidenced  by  the  International  Organization  for 
Standardization/International  Electrotechnical  Commission  (ISO/IEC) 
body  of  standards. 

Capability  maturity  models  (CMMs)  focus  on  improving  processes  in  an 
organization.  They  contain  the  essential  elements  of  effective 
processes  for  one  or  more  disciplines  and  describe  an  evolutionary 
improvement  path  from  ad  hoc,  immature  processes  to  disciplined, 
mature  processes  with  improved  quality  and  effectiveness. 

Mark  Paulk  and  others  at  the  Software  Engineering  Institute  created  the 
first  capability  maturity  model  designed  for  software  organizations  and 
published  it  in  a  book,  The  Capability  Maturity  Model:  Guidelines  for 
Improving  the  Software  Process  [SEI  1995],  The  value  of  this  process 
improvement  approach  has  been  confirmed  overtime.  Organizations 
have  experienced  increased  productivity  and  quality,  improved  cycle 
time,  and  more  accurate  and  predictable  schedules  and  budgets5 


5  From  the  forthcoming  SEI  technical  report.  Performance  Results  of  CMMI-Bcised  Process  Improvement  by 
Diane  L.  Gibson,  Dennis  R.  Goldenson,  and  Keith  Kost. 
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Evolution  of  CMMI 


Since  1991,  CMMs  have  been  developed  fora  myriad  of  disciplines. 
Some  of  the  most  notable  include  models  for  systems  engineering, 
software  engineering,  software  acquisition,  workforce  management  and 
development,  and  integrated  product  and  process  development. 

Although  these  models  have  proved  useful  to  many  organizations  in 
different  industries,  the  use  of  multiple  models  has  been  problematic. 
Many  organizations  would  like  their  improvement  efforts  to  span 
different  groups  in  their  organizations.  However,  the  differences  among 
these  discipline-specific  models  used  by  each  group,  including  their 
architecture,  content,  and  approach,  have  limited  these  organizations’ 
ability  to  broaden  their  improvements  successfully.  Further,  applying 
multiple  models  that  are  not  integrated  within  and  across  an 
organization  is  costly  in  terms  of  training,  appraisals,  and  improvement 
activities. 

The  CMM  Integration  project  was  formed  to  sort  out  the  problem  of 
using  multiple  CMMs.  The  CMMI  Product  Team’s  initial  mission  was  to 
combine  three  source  models: 

1 .  The  Capability  Maturity  Model  for  Software  (SW-CMM)  v2.0  draft  C 
[SEI  1997b] 

2.  The  Systems  Engineering  Capability  Model  (SECM)  [EIA  1998] 

3.  The  Integrated  Product  Development  Capability  Maturity  Model  (IPD- 
CMM)v  0.98  [SEI  1997a] 

The  combination  of  these  models  into  a  single  improvement  framework 
was  intended  for  use  by  organizations  in  their  pursuit  of  enterprise-wide 
process  improvement. 

These  three  source  models  were  selected  because  of  their  widespread 
adoption  in  the  software  and  systems  engineering  communities  and 
because  of  their  different  approaches  to  improving  processes  in  an 
organization. 

Using  information  from  these  popular  and  well-regarded  models  as 
source  material,  the  CMMI  Product  Team  created  a  cohesive  set  of 
integrated  models  that  can  be  adopted  by  those  currently  using  the 
source  models,  as  well  as  by  those  new  to  the  CMM  concept.  Hence, 
CMMI  is  a  result  of  the  evolution  of  the  SW-CMM,  the  SECM,  and  the 
IPD-CMM. 


6 


About  CMMI 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Developing  a  set  of  integrated  models  involved  more  than  simply 
adding  existing  model  materials  together.  Using  processes  that  promote 
consensus,  the  CMMI  Product  Team  built  a  framework  that 
accommodates  multiple  disciplines  and  is  flexible  enough  to  support  the 
different  approaches  of  the  source  models. 

Since  the  release  of  CMMI  vl  .1 ,  which  is  focused  on  product  and 
service  development,  we  have  seen  that  this  improvement  framework 
can  be  applied  to  other  areas  of  interest.  To  apply  to  multiple  areas  of 
interest,  the  framework  groups  best  practices  into  what  we  call 
“constellations.”  A  constellation  is  a  collection  of  CMMI  components  that 
are  used  to  build  models,  training  materials,  and  appraisal  documents. 
Currently  there  are  three  constellations  planned  to  be  supported  by  the 
Version  1.2  model  framework:  development,  services,  and  acquisition. 
Figure  1.2  illustrates  the  history  of  how  CMMI  was  developed  and  has 
grown,  [acq] 


History  of  CMMs 


Figure  1.2:  The  History  of  CMMs  [acqi 

Recently,  the  CMMI  model  architecture  was  improved  to  support 
multiple  constellations  and  the  sharing  of  best  practices  among 
constellations  and  their  member  models.  The  CMMI  models  that  have 
been  available  in  the  community  prior  to  2006  are  now  considered  part 
of  the  CMMI  for  Development  constellation. 
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CMMI  for  Acquisition 


General  Motors  partnered  with  the  SEI  to  create  the  initial  draft  CMMI 
for  Acquisition  described  in  this  document.  An  organization  should  use 
professional  judgment  and  common  sense  to  interpret  this  document  for 
its  organization.  That  is,  although  the  process  areas  described  here 
depict  behaviors  considered  best  practice  for  most  organizations,  all 
process  areas  and  practices  are  to  be  interpreted  using  an  in-depth 
knowledge  of  the  CMMI  model  (including  the  initial  draft  CMMI-ACQ) 
being  used,  organizational  constraints,  the  business  environment,  and 
other  circumstances  involved,  [acq] 

Practices  essential  for  executing  acquisition  processes  are  performed 
slightly  differently  or  with  differing  roles  when  focused  either  on  the 
acquirer  or  the  interaction  with  the  supplier.  These  differences  are 
particularly  apparent  in  activities  such  as  monitoring,  directing,  or 
overseeing  a  supplier,  which  occur  after  a  source  selection  or 
authorization  for  a  supplier  to  begin  work  is  accomplished,  [acq] 

This  document  is  to  be  considered  as  an  initial  draft  CMMI-ACQ  for  the 
Acquisition  constellation.  The  best  practices  contained  in  the  initial  draft 
CMMI-ACQ  have  gone  through  an  extensive  review  process.  The 
Product  Team  evaluated  more  than  1 ,000  comments  and  change 
requests  from  acquisition  organizations  as  well  as  suppliers  to  create 
the  initial  draft  CMMI-ACQ.  [ACQ] 


The  Scope  of  CMMI  for  Acquisition 


This  document  describes  a  draft  reference  model  that  covers  the 
acquisition  of  technical  solutions.  There  are  acquirers  of  technology 
solutions  from  many  industries  including  aerospace,  banking,  computer 
hardware,  software,  defense,  automobile  manufacturing,  and 
telecommunications  that  can  use  CMMI  for  Acquisition,  [acq] 

The  initial  draft  CMMI-ACQ  contains  unique  acquisition  practices  in  six 
process  area  that  cover  solicitation  and  supplier  agreement 
development,  acquisitions  management,  acquisition  requirements 
development,  acquisitions  technical  solution,  acquisition  validation,  and 
acquisition  verification.  The  six  processes  areas  are  supplemented  by 
16  process  areas  that  cover  project  management,  organizational  and 
support  process  areas.  These  16  processes  are  necessary  but  not 
sufficient  to  executing  as  a  successful  acquirer,  [acq] 
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2  Process  Area  Components 


This  chapter  describes  the  components  that  comprise  each  process 
area,  generic  goal,  and  generic  practice  of  the  initial  draft  CMMI-ACQ. 
Understanding  the  meaning  of  these  components  is  critical  to  using  the 
information  in  Part  Two  effectively.  If  you  are  unfamiliar  with  Part  Two, 
you  may  want  to  skim  the  Generic  Goals  and  Practices  section  and  a 
couple  of  process  area  sections  to  get  a  general  feel  for  the  content  and 
layout  before  reading  this  chapter,  [acq] 


Required,  Expected,  and  Informative  Components 


Model  components  are  grouped  into  three  categories — required, 
expected,  and  informative — that  reflect  how  to  interpret  them. 

Required  Components 


Required  components  describe  what  an  organization  must  achieve  to 
satisfy  a  process  area.  This  achievement  must  be  visibly  implemented 
in  an  organization’s  processes.  The  required  components  in  CMMI  are 
the  specific  and  generic  goals.  Goal  satisfaction  is  used  in  appraisals  as 
the  basis  for  deciding  if  a  process  area  has  been  achieved  and 
satisfied. 

Expected  Components 


Expected  components  describe  what  an  organization  will  typically 
implement  to  achieve  a  required  component.  Expected  components 
guide  those  who  implement  improvements  or  perform  appraisals. 
Expected  components  include  the  specific  and  generic  practices. 

Before  goals  can  be  considered  satisfied,  either  the  practices  as 
described  or  acceptable  alternatives  to  them  are  present  in  the  planned 
and  implemented  processes  of  the  organization. 
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Informative  Components 


Informative  components  provide  details  that  help  organizations  get 
started  in  thinking  about  how  to  approach  the  required  and  expected 
components.  Subpractices,  typical  acquirer  work  products,  typical 
supplier  deliverables,  amplifications,  goal  and  practice  titles,  goal  and 
practice  notes,  and  references  are  all  informative  model  components. 

[ACQ] 


The  CMMI  glossary  of  terms  is  not  a  required,  expected,  or  informative 
element  of  CMMI  models.  The  terms  in  the  glossary  should  be 
interpreted  in  the  context  of  the  model  component  in  which  they  appear. 


Components  Associated  with  Part  Two 


The  model  components  associated  with  Part  Two  can  be  summarized 
to  illustrate  their  relationships,  as  in  Figure  2. 1 .  Within  Part  2,  generic 
goals  and  practices  are  described  separately  from  the  individual 
process  areas,  but  they  apply  to  all  process  areas,  [acq] 


KEY: 


Figure  2.1:  CMMI  Model  Components 


The  following  sections  provide  detailed  descriptions  of  the  model 
components. 
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Process  Areas 

A  process  area  is  a  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfies  a  set  of  goals  considered  important 
for  making  significant  improvement  in  that  area. 

There  are  twenty-two  process  areas,  presented  in  alphabetical  order  by 
acronym:  [acqj 

•  Acquisition  Management  (AM) 

•  Acquisition  Requirements  Development  (ARD) 

•  Acquisition  Technical  Solution  (ATS) 

•  Acquisition  Validation  (AVAL) 

•  Acquisition  Verification  (AVER) 

•  Causal  Analysis  and  Resolution  (CAR) 

•  Configuration  Management  (CM) 

•  Decision  Analysis  and  Resolution  (DAR) 

•  Integrated  Project  Management  (IPM) 

•  Measurement  and  Analysis  (MA) 

•  Organizational  Innovation  and  Deployment  (OID) 

•  Organizational  Process  Definition  (OPD) 

•  Organizational  Process  Focus  (OPF) 

•  Organizational  Process  Performance  (OPP) 

•  Organizational  Training  (OT) 

•  Project  Monitoring  and  Control  (PMC) 

•  Project  Planning  (PP) 

•  Process  and  Product  Quality  Assurance  (PPQA) 

•  Quantitative  Project  Management  (QPM) 

•  Requirements  Management  (REQM) 

•  Risk  Management  (RSKM) 

•  Solicitation  and  Supplier  Agreement  Development  (SSAD) 

Purpose  Statements 

The  purpose  statement  describes  the  purpose  of  the  process  area  and 
is  an  informative  component. 

For  example,  the  purpose  statement  of  the  Organizational  Process 
Definition  process  area  is  “The  purpose  of  Organizational  Process 
Definition  (OPD)  is  to  establish  and  maintain  a  usable  set  of 
organizational  process  assets  and  work  environment  standards.”  [acq] 


About  CMMI 


11 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Introductory  Notes 


The  introductory  notes  section  of  the  process  area  describes  the  major 
concepts  covered  in  the  process  area  and  is  an  informative  component. 

An  example  from  the  introductory  notes  of  the  Project  Planning  process 
area  is  “Planning  begins  with  requirements  that  define  the  product  and 
project.” 

Related  Process  Areas 


The  related  process  areas  section  lists  references  to  related  process 
areas  and  reflects  the  high-level  relationships  among  the  process 
areas.  The  related  process  area  section  is  an  informative  component. 

An  example  of  a  reference  found  in  the  related  process  areas  section  of 
the  Project  Planning  process  area  is  “Refer  to  the  Risk  Management 
process  area  for  more  information  about  identifying  and  managing 
risks.” 

Specific  Goals 


A  specific  goal  describes  the  unique  characteristics  that  must  be 
present  to  satisfy  the  process  area.  A  specific  goal  is  a  required  model 
component  and  is  used  in  appraisals  to  help  determine  whether  a 
process  area  is  satisfied. 

For  example,  a  specific  goal  from  the  Configuration  Management 
process  area  is  “Integrity  of  baselines  is  established  and  maintained.” 

Only  the  statement  of  the  specific  goal  is  a  required  model  component. 
The  title  of  a  specific  goal  (preceded  by  the  goal  number)  and  any  notes 
associated  with  the  goal  are  considered  informative  model  components. 

Generic  Goals 


Generic  goals  appear  in  Part  Two  as  a  separate  section  and  are  called 
“generic”  because  all  generic  goal  statements  apply  to  all  process 
areas.  A  generic  goal  describes  the  characteristics  that  must  be  present 
to  institutionalize  the  processes  that  implement  a  process  area.  A 
generic  goal  is  a  required  model  component  and  is  used  in  appraisals  to 
determine  whether  a  process  area  is  satisfied.  (See  Generic  Goals  and 
Practices  section  in  Part  Two  for  a  more  detailed  description  of  generic 
goals.)  [acq] 

An  example  of  a  generic  goal  is  “The  process  is  institutionalized  as  a 
defined  process.” 
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Only  the  statement  of  the  generic  goal  is  a  required  model  component. 
The  title  of  a  generic  goal  (preceded  by  the  goal  number)  and  any  notes 
associated  with  the  goal  are  considered  informative  model  components. 

Specific  Goal  and  Practice  Summary 


The  specific  goal  and  practice  summary  provides  a  high-level  summary 
of  the  specific  goals  that  are  required  components  and  the  specific 
practices  that  are  expected  components.  The  specific  goal  and  practice 
summary  is  an  informative  component. 

Specific  Practices 


A  specific  practice  is  the  description  of  an  activity  that  is  considered 
important  in  achieving  the  associated  specific  goal.  The  specific 
practices  describe  the  activities  that  are  expected  to  result  in 
achievement  of  the  specific  goals  of  a  process  area.  A  specific  practice 
is  an  expected  model  component. 

For  example,  a  specific  practice  from  the  Project  Monitoring  and  Control 
process  area  is  “Monitor  commitments  against  those  identified  in  the 
project  plan.” 

Only  the  statement  of  the  specific  practice  is  an  expected  model 
component.  The  title  of  a  specific  practice  (preceded  by  the  practice 
number)  and  any  notes  associated  with  the  specific  practice  are 
considered  informative  model  components. 

Typical  Acquirer  Work  Products 


The  typical  acquirer  work  products  section  lists  sample  outputs  from  a 
specific  practice.  These  examples  are  called  “typical  acquirer  work 
products”  because  there  are  often  other  work  products  that  are  just  as 
effective  but  are  not  listed,  [acq] 

For  example,  a  typical  acquirer  work  product  for  the  specific  practice 
“Establish  and  maintain  verification  procedures  and  criteria  for  the 
selected  work  products”  in  the  Acquisition  Verification  process  area  is 
“verification  criteria.”  [acqj 

Typical  Supplier  Deliverables 


To  aid  the  acquirer,  typical  supplier  deliverables  examples  are  also 
provided.  These  deliverables  represent  artifacts  that  are  input  to  or 
support  the  acquirer’s  implementation  of  the  practice.  All  deliverables 
required  by  the  acquirer  are  to  be  included  in  the  supplier  agreement. 

[ACQ] 
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For  example,  a  typical  supplier  deliverable  for  the  specific  practice 
“Select  the  work  products  to  be  verified  and  the  verification  methods 
that  will  be  used  for  each”  in  the  Acquisition  Verification  process  area  is 
“list  of  supplier  deliverables.”  [acq] 

Subpractices 


A  subpractice  is  a  detailed  description  that  provides  guidance  for 
interpreting  and  implementing  a  specific  or  generic  practice. 
Subpractices  may  be  worded  as  if  prescriptive,  but  are  actually  an 
informative  component  meant  only  to  provide  ideas  that  may  be  useful 
for  process  improvement. 

For  example,  a  subpractice  for  the  specific  practice  “Take  corrective 
action  on  identified  issues”  in  the  Project  Monitoring  and  Control 
process  area  is  “Determine  and  document  the  appropriate  actions 
needed  to  address  the  identified  issues.” 

Generic  Practices 


Generic  practices  appear  with  generic  goals  in  a  section  Part  Two  and 
are  called  “generic”  because  all  generic  practice  statements  apply  to  all 
process  areas.  A  generic  practice  is  the  description  of  an  activity  that  is 
considered  important  in  achieving  the  associated  generic  goal.  A 
generic  practice  is  an  expected  model  component,  [acq] 

For  example,  a  generic  practice  for  the  generic  goal  “The  process  is 
institutionalized  as  a  managed  process”  is  “Provide  adequate  resources 
for  performing  the  process,  developing  the  work  products,  and  providing 
the  services  of  the  process.” 

Only  the  statement  of  the  generic  practice  is  an  expected  model 
component.  The  title  of  a  generic  practice  (preceded  by  the  practice 
number)  and  any  notes  associated  with  the  practice  are  considered 
informative  model  components. 


Supporting  Informative  Components 


There  are  many  places  where  further  information  is  needed  to  describe 
a  concept.  This  informative  material  is  provided  in  the  form  of  the 
following  components: 

•  Notes 

•  Examples 

•  Amplifications 

•  References 
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Notes 


A  note  is  text  that  can  accompany  nearly  any  other  model  component.  It 
may  provide  detail,  background,  or  rationale.  A  note  is  an  informative 
model  component. 

For  example,  a  note  that  accompanies  the  specific  practice  “Implement 
the  selected  action  proposals  that  were  developed  in  causal  analysis”  in 
the  Causal  Analysis  and  Resolution  process  area  is  “Only  changes  that 
prove  to  be  of  value  should  be  considered  for  broad  implementation.” 

Examples 


An  example  is  a  component  comprising  text  and  often  a  list  of  items, 
usually  in  a  box,  that  can  accompany  nearly  any  other  component  and 
provides  one  or  more  examples  to  clarify  a  concept  or  described 
activity.  An  example  is  an  informative  model  component. 

The  following  is  an  example  that  accompanies  the  subpractice 
“Document  noncompliance  issues  when  they  cannot  be  resolved  within 
the  project"  under  the  specific  practice  “Communicate  quality  issues 
and  ensure  resolution  of  noncompliance  issues  with  the  staff  and 
managers.” 

Amplifications 


There  are  two  types  of  amplifications:  those  that  apply  to  disciplines  and 
those  that  apply  to  additions.  An  amplification  is  informative  material 
that  is  relevant  to  a  particular  discipline  or  addition.  Each  amplification  is 
labeled  with  a  tag  [ACQ]  that  indicates  this  amplification  applies  to  the 
acquisition  discipline,  [acq] 

References 


A  reference  is  a  pointer  to  additional  or  more  detailed  information  in 
related  process  areas  and  can  accompany  nearly  any  other  model 
component.  A  reference  is  an  informative  model  component. 

For  example,  a  reference  that  accompanies  the  specific  practice  “Select 
the  subprocesses  that  compose  the  project’s  defined  process  based  on 
historical  stability  and  capability  data”  in  the  Quantitative  Project 
Management  process  area  is  “Refer  to  the  Organizational  Process 
Definition  process  area  for  more  information  about  the  organization’s 
process  asset  library,  which  might  include  a  process  element  of  known 
and  needed  capability.” 
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Numbering  Scheme 


Specific  and  generic  goals  are  numbered  sequentially.  Each  specific 
goal  begins  with  the  prefix  SG  (e.g.,  SG  1).  Each  generic  goal  begins 
with  the  prefix  GG  (e.g.,  GG  2). 

Each  specific  practice  begins  with  the  prefix  SP,  followed  by  a  number 
in  the  form  x.y  (e.g.,  SP  1.1).  The  x  is  the  same  number  as  the  goal  the 
specific  practice  maps  to.  The  y  is  the  sequence  number  of  the  specific 
practice  under  the  specific  goal. 

An  example  of  specific  practice  numbering  is  in  the  Project  Planning 
process  area.  The  first  specific  practice  is  numbered  SP  1.1  and  the 
second  is  SP  1 .2. 

Each  generic  practice  begins  with  the  prefix  GP,  followed  by  a  number 
in  the  form  x.y  (e.g.,  GP  1.1). 

The  x  corresponds  to  the  number  of  the  generic  goal.  The  y  is  the 
sequence  number  of  the  generic  practice  under  the  generic  goal.  For 
example,  the  first  generic  practice  associated  with  GG  2  is  numbered 
GP  2.1 . 


Typographical  Conventions 


The  typographical  conventions  used  in  this  document  were  designed  to 
enable  you  to  select  what  you  need  and  use  it  effectively.  We  present 
model  components  in  formats  that  allow  you  to  find  them  quickly  on  the 
page.  [ACQ] 


Figures  2.2  through  2.3  are  sample  pages  from  process  areas  in  Part 
Two;  they  show  the  different  process  area  components,  labeled  so  that 
you  can  identify  them.  Notice  that  components  differ  typographically  so 
that  you  can  easily  identify  each  one. 
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Process 
Area 


Introductory 

Notes 


PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 


A  Support  Process  Area  at  Maturity  level  2 


Purpose 


The  purpose  of  Process  and  Product  Quality  Assurance  (PPQA)  is  to 
provide  staff  and  management  with  objective  insight  into  processes  and 
associated  work  products 


Introductory  Notes 


The  Process  and  Product  Quality  Assurance  process  area  involves  the 
following: 

•  Objectively  evaluating  performed  processes,  work  products,  and 
services  against  the  applicable  process  descriptions,  standards, 
and  procedures 

•  Identifying  and  documenting  noncompliance  issues 

•  Providing  feedback  to  project  staff  and  managers  on  the  results  of 
quality  assurance  activities 

•  Ensuring  that  noncompliance  issues  are  addressed 

The  Process  and  Product  Quality  Assurance  process  area  supports  the 
delivery  of  high-quality  products  and  services  by  providing  the  project 
staff  and  managers  at  all  levels  with  appropriate  visibility  into,  and 
feedback  on.  processes  and  associated  work  products  throughout  the 
life  of  the  project 

The  acquirer  evaluates  critical  acquirer  work  products,  acquirer 
processes,  results  of  supplier's  process  quality  assurance  and  supplier 
deliverables  For  example,  process  and  product  quality  assurance 
ensures  that  the  solicitation  package  was  developed  per  the  standard 
processes  agreed  to  by  the  organization  and  that  it  conforms  to  all 
applicable  policies  The  acquirer  may  review  the  results  of  the  supplier's 
quality  assurance  activities  for  selected  supplier  processes  to  ensure 
that  the  supplier  is  following  its  own  processes  Typically,  selected 
supplier  processes  would  be  critical  processes,  such  as  engineenng  or 
verification  processes,  where  the  supplier  is  required  through  the 
supplier  agreement  to  follow  project-specified  standards  In  exceptional 
cases,  the  acquirer  may  directly  perform  product  and  process  quality 
assurance  for  selected  supplier  processes  The  acquirer  and  supplier 
periodically  share  quality  assurance  issues  and  findings  that  are  of 
mutual  interest  pcoj 


Process  and  Product  Quality  Assurance 


Figure  2.2:  Sample  Page  from  Process  and  Product  Quality 
Assurance  [acqi 


Purpose 
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Subpractices  - 


Specific 
Goal 


Typical 
Acquirer 
Work  “ 
Products 


Establish  in  the  supplier  agreement  the  verification  methods  such 
as  acceptance  criteria  for  supplier  deliverables  and  other  work 
products 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  - 
information  about  the  use  of  measurements 

Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new 
requirements. 

These  criteria  may  be  denned  by  the  acquirer  tor  cnical  suppler  work  products 
only,  as  identited  under  tie  Select  Work  Products  For  Verlcatwn  practice 

The  peer  review  is  an  important  and  effective  engneerng  metiod  implemented 
via  rspections,  stuctured  waikrroughs.  or  a  number  of  otier  co legal  review 
me  tods 


SG  2  Verify  Selected  Work  Products 


Selected  worK  products  ore  verified  against  their  contractual 
requirements. 

The  verification  methods,  procedures,  and  criteria  are  used  to  verify  the 
selected  work  products  and  any  associated  maintenance,  training,  and 
support  services  using  the  appropriate  venfication  environment 
Verification  activities  should  be  performed  throughout  the  project 
lifecycle 


SP2.1 


Perfonn  Verification 


Perform  verification  on  the  selected  work  products. 

Verifying  acquired  products  and  work  products  incrementally  promotes 
early  detection  of  problems  and  can  result  in  the  early  removal  of 
defects.  The  results  of  verification  save  considerable  cost  of  fault 
isolation  and  rework  associated  with  troubleshooting  problems 

Typical  Acquirer  Work  Products 

1  Verification  results 


2  Verification  reports 
3.  Demonstrations 
4  As-run  procedures  log 

Typical  Supplier  Deliver  ablee 

1  Verification  results 


2  Verification  reports 


Acquisition  Verification 


Reference 


^Specific 

Practice 


Typical 

Supplier 

Deliverables 


Figure  2.3:  Sample  Page  from  Acquisition  Verification  iacoj 
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3  Tying  It  All  Together 


Now  that  you  have  been  introduced  to  the  components  of  CMMI® 
models,  you  need  to  understand  how  they  all  fit  together  to  meet  your 
process  improvement  needs.  This  chapter  introduces  the  concept  of 
levels  and  shows  how  the  process  areas  are  organized  and  used. 

The  initial  draft  CMMI-ACQ  does  not  specify  that  a  project  or  acquirer 
follows  a  particular  acquisition  process  flow  or  that  a  certain  number  of 
“deliverables  per  day”  or  specific  performance  targets  are  achieved  - 
only  that  they  have  processes  in  place  for  adequately  addressing 
acquisition-related  practices.  To  determine  whether  this  is  so,  a  project 
or  organization  maps  its  processes  to  the  process  areas  contained  in 
this  document,  [acq] 

The  mapping  of  its  processes  to  process  areas  allows  an  acquirer  to 
track  progress  to  the  initial  draft  CMMI-ACQ  as  incremental  process 
improvement  or  innovations  are  successfully  deployed.  It  is  not 
intended  that  every  process  area  of  the  initial  draft  CMMI-ACQ  maps 
one  to  one  with  a  given  organization’s  or  project’s  processes,  [acqj 


Understanding  Levels 


Levels  are  used  in  CMMI  to  describe  an  evolutionary  path 
recommended  for  an  organization  that  wants  to  improve  the  processes 
it  uses  to  acquire  its  products  and  services.  Levels  can  also  be  the 
outcome  of  the  rating  activity  of  appraisals.6  Appraisals  can  apply  to 
organizations  that  comprise  entire  companies,  or  to  smaller  groups 
such  as  a  small  group  of  projects  or  a  division  within  a  company,  [acq] 

CMMI  supports  two  improvement  approaches.  The  first  utilizes  what  is 
called  the  continuous  representation;  the  continuous  representation  is 
based  on  capability  levels.  The  second  utilizes  what  is  called  the  staged 
representation;  the  staged  representation  is  based  on  maturity  levels. 

[ACQ] 


6  For  more  information  about  appraisals,  see  the  forthcoming  Appraisal  Requirements  for  CMMI  and  the 
Standard  CMMI  Appraisal  Method  for  Process  Improvement  Method  Definition  Document. 
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Understanding  Capability  Levels 


To  support  those  using  the  continuous  representation,  all  CMMI  models 
reflect  capability  levels  in  their  design  and  content.  A  capability  level 
consists  of  a  generic  goal  and  its  related  generic  practices  for  a  process 
area  that  can  improve  the  organization’s  processes  associated  with  that 
process  area.  As  you  satisfy  the  generic  goal  and  its  generic  practices 
at  each  capability  level,  you  reap  the  benefits  of  process  improvement 
for  that  process  area. 

The  six  capability  levels,  designated  by  the  numbers  0  through  5,  are 
0.  Incomplete 

1 .  Performed 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 

The  fact  that  capability  levels  2  through  5  use  the  same  terms  as 
generic  goals  2  through  5  is  intentional  because  each  of  these  general 
goals  and  practices  reflects  the  meaning  of  the  capability  levels  in  terms 
of  goals  and  practices  you  can  implement.  (See  the  Generic  Goals  and 
Practices  section  in  Part  Two  for  more  information  about  generic  goals 
and  practices.) 

The  five  capability  levels  are  described  as  follows7:  [acq] 

•  Achieving  CL  1  ("Performed")  means  you  have  satisfied  all  the 
specific  goals  of  the  process  area;  otherwise  you  are  CL  0  (“Not 
Performed”)  relative  to  that  process  area. 

•  Achieving  CL  2  ("Managed")  relative  to  a  process  area  means  you 
have  achieved  CL  1  in  that  process  area  and  in  addition  have 
satisfied  generic  goal  2  and  all  its  associated  generic  practices. 

•  Achieving  CL  3  ("Defined")  relative  to  a  process  area  means  you 
have  achieved  CL  2  in  that  process  area  and  in  addition  have 
satisfied  generic  goal  3  and  all  its  associated  generic  practices. 


7  The  initial  draft  CMMI-ACQ  was  designed  to  support  those  seeking  to  apply  the  staged  rather  than  continuous 
representation-based  improvement  approach.  As  a  result,  the  description  of  capability  levels  has  been 
shortened.  Those  seeking  to  use  the  continuous  representation  are  encouraged  to  consult  the  Generic  Goals  and 
Practices  section  in  Part  Two  for  the  subsection  that  describes  generic  practice  and  process  area  interactions, 
which  are  important  to  understand  when  selecting  which  process  areas  to  implement  first.  Also,  chapters  3  and 
4  of  the  CMMI  for  Development,  vl.2  provide  additional  information. 
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•  Achieving  CL  4  ("Quantitatively  Managed")  relative  to  a  process 
area  means  you  have  achieved  CL  3  in  that  process  area  and  in 
addition  have  satisfied  generic  goal  4  and  all  its  associated  generic 
practices. 

•  Achieving  CL  5  ("Optimizing")  relative  to  a  process  area  means  you 
have  achieved  CL  4  in  that  process  area  and  in  addition  have 
satisfied  generic  goal  5  and  all  its  associated  generic  practices. 


Understanding  Maturity  Levels 


If  you  do  not  know  where  to  start  and  which  processes  to  choose  to 
improve,  the  staged  representation  is  a  good  choice  for  you.  It  gives 
you  a  specific  set  of  processes  to  start  improving  as  an  acquirer  of 
technology  solutions.  The  following  sections  will  describe  the  process 
areas  contained  in  each  maturity  level.  There  are  five  maturity  levels, 
each  a  layer  in  the  foundation  for  ongoing  process  improvement, 
designated  by  the  numbers  1  through  5:  [acq] 

1.  Initial 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 


Maturity  Level  1:  Initial 


At  maturity  level  1 ,  processes  are  usually  ad  hoc  and  chaotic.  The 
organization  usually  does  not  provide  a  stable  environment  to  support 
the  processes.  Success  in  these  organizations  depends  on  the 
competence  and  heroics  of  the  people  in  the  organization  and  not  on 
the  use  of  proved  processes.  In  spite  of  this  chaotic  environment, 
maturity  level  1  organizations  acquire  products  and  services  that  often 
work;  however,  they  frequently  exceed  the  budget  and  schedule 
documented  in  their  plans,  [acqj 

Maturity  level  1  organizations  are  characterized  by  a  tendency  to 
overcommit,  abandonment  of  processes  in  a  time  of  crisis,  and  an 
inability  to  repeat  their  successes. 
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Maturity  Level  2:  Managed 


At  maturity  level  2,  projects  establish  the  foundation  for  an  organization 
to  become  an  effective  acquirer  of  technology  solutions  by 
institutionalizing  basic  project  management  and  supplier  agreement 
management  practices.  The  acquirer  ensures  that  processes  are 
planned  and  executed  in  accordance  with  policy,  employ  skilled  people 
who  have  adequate  resources  to  produce  controlled  outputs,  and 
involve  relevant  stakeholders;  that  projects  are  monitored  and 
controlled;  and  that  selected  work  products  and  processes  are 
objectively  evaluated  for  adherence  to  their  process  descriptions.  The 
process  discipline  reflected  by  maturity  level  2  helps  to  ensure  that 
existing  practices  are  retained  during  times  of  stress,  [acq] 

At  maturity  level  2,  requirements,  processes,  work  products,  and 
services  are  managed.  The  status  of  the  work  products  and  the  delivery 
of  services  are  visible  to  management  at  defined  points  (for  example,  at 
major  milestones  and  at  the  completion  of  major  tasks).  Commitments 
are  established  among  relevant  stakeholders  and  are  revised  as 
needed.  Work  products  are  reviewed  with  stakeholders  and  are 
controlled.  The  work  products  and  services  satisfy  their  specified 
requirements,  standards,  and  objectives,  [acq] 

Figure  3.1  provides  an  overview  of  the  maturity  level  2  process  areas 
and  some  of  their  more  significant  interactions.  The  relationships  shown 
are  notional  and  are  not  intended  to  portray  all  possible  interactions  or 
all  required  interactions,  [acq] 
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QA  Results 


Measurement  Results., 


/  Measurement  \ 
1  and  Analysis 


Measurement  Objectives 
Required  Measures 


Project  Plan 


Project 
"A  Monitoring 
V  and  Control 

— ' Vv. 

/ 


Project  Performance  Results 
Escalated  Issues/Disputes 


Corrective  Action  Reports 


Process  and' 
Product  \ 
Quality  / 
.Assurance  / 


Project  Objectives 
Service  Level  Agreements 


Required  QA  Reports 


Project  Objectives 
Service  Level  Agreements 


Requirements  Traceability 
Change  Requests 


Invoices 

Supplier  Performance  Report 
Acquirer  Satisfaction  Survey 


Acquisition  Strategy 
Project  Plan 


Supplier  Agreement 
Project  Plan 

/ 


I  Requirements 
\  Management  J 


/  Solicitation  \ 
and  Supplier  \ 
\  Agreement 
V^evelopmenj/ 


'  Acquisition  \ 
Management ) 


Figure  3. 1:  Maturity  Level  2  Process  Areas  [acqj 


The  Solicitation  and  Supplier  Agreement  Development  process  area 
defines  practices  to  prepare  a  solicitation  package,  to  select  a  capable 
supplier  and  to  establish  the  supplier  agreement.  Acquisition 
Management  focuses  on  maintaining  the  supplier  agreement  including 
dispute  resolution  and  managing  the  relationship  with  the  supplier.  This 
includes  managing  payments  to  suppliers  and  ongoing  communications 
with  suppliers,  [acq] 

Project  planning  establishes  and  maintains  plans  that  define  project 
activities.  This  includes  planning  for  transition  of  the  product  into 
operations  and  support.  After  a  supplier  is  selected  and  a  supplier 
agreement  is  established,  the  acquirer  continues  to  apply  Requirements 
Management  practices  to  manage  the  customer  and  contractual 
requirements,  while  the  selected  supplier  is  managing  the  refined 
product  and  product  component  requirements.  The  Project  Monitoring 
and  Control  process  area  is  concerned  with  monitoring  and  control  of 
acquirer  activities  and  overseeing  the  progress  and  performance  of  the 
supplier’s  execution  according  to  the  project  plans,  [acq] 
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An  acquirer  uses  the  Measurement  and  Analysis  process  area  practices 
to  support  the  information  needs  of  the  business,  organization  and 
project.  Some  of  this  information  may  be  needed  from  the  acquirer, 
some  from  the  supplier,  and  some  from  all  parts  of  a  project.  All 
information  required  from  the  supplier  must  be  designated  in  the 
supplier  agreement.  The  Process  and  Product  Quality  Assurance 
process  area  objectively  evaluates  selected  acquirer  work  products  and 
processes,  [acq] 


Configuration  Management  (not  depicted  in  Figure  3.1)  establishes  and 
maintains  the  integrity  of  work  products  such  as  solicitation  packages 
using  configuration  identification,  configuration  control,  configuration 
status  accounting,  and  configuration  audits.  In  addition,  configuration 
management  of  acquired  products  (both  final  and  interim  products) 
created  by  the  suppliers  require  monitoring  to  ensure  that  project  goals 
are  met.  [acq] 


Maturity  Level  3:  Defined 


At  maturity  level  3,  acquirers  are  using  defined  processes  for 
establishing  and  managing  standard  supplier  agreements,  and  they 
embed  tenets  of  project  management  and  engineering  best  practices, 
such  as  requirements  development  and  establishing  design  constraints, 
into  the  standard  process  set.  These  processes  are  well  characterized 
and  understood,  and  are  described  in  standards,  procedures,  tools,  and 
methods,  [acq] 

The  organization’s  set  of  standard  processes,  which  is  the  basis  for 
maturity  level  3,  is  established  and  improved  over  time.  These  standard 
processes  are  used  to  establish  consistency  across  the  organization. 
Projects  establish  their  defined  processes  by  tailoring  the  organization’s 
set  of  standard  processes  according  to  tailoring  guidelines. 

A  critical  distinction  between  maturity  levels  2  and  3  is  the  scope  of 
standards,  process  descriptions,  and  procedures.  At  maturity  level  2, 
the  standards,  process  descriptions,  and  procedures  may  be  quite 
different  in  each  specific  instance  of  the  process  (e.g.,  on  a  particular 
project).  At  maturity  level  3,  the  standards,  process  descriptions,  and 
procedures  for  a  project  are  tailored  from  the  organization’s  set  of 
standard  processes  to  suit  a  particular  project  or  organizational  unit  and 
therefore  are  more  consistent  except  for  the  differences  allowed  by  the 
tailoring  guidelines. 
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Another  critical  distinction  is  that  at  maturity  level  3,  processes  are 
typically  described  more  rigorously  than  at  maturity  level  2.  A  defined 
process  clearly  states  the  purpose,  inputs,  entry  criteria,  activities,  roles, 
measures,  verification  steps,  outputs,  and  exit  criteria.  At  maturity  level 
3,  processes  are  managed  more  proactively  using  an  understanding  of 
the  interrelationships  of  the  process  activities  and  detailed  measures  of 
the  process,  its  work  products,  and  its  services. 

At  maturity  level  3,  the  organization  must  further  mature  the  maturity 
level  2  process  areas.  The  generic  practices  associated  with  Generic 
Goal  3  that  were  not  addressed  at  maturity  level  2  are  applied  to 
achieve  maturity  level  3. 

Figure  3.2  provides  an  overview  of  the  maturity  level  3  process  areas 
and  some  of  their  more  significant  interactions.  The  relationships  shown 
are  notional  and  are  not  intended  to  portray  all  possible  interactions  or 
all  required  interactions,  [acq] 
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Figure  3.2:  Maturity  Level  3  Process  Areas  [acqj 


Due  to  the  acquirer-supplier  relationship,  the  need  for  an  early  and 
aggressive  detection  of  risk  is  compounded  by  the  complexity  of 
projects  acquiring  products  or  services.  The  purpose  of  Risk 
Management  is  to  identify  and  assess  project  risks  during  the  project 
planning  process  and  managing  these  risks  throughout  the  project,  [acq] 
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The  acquirer  has  a  dual  role:  first,  to  assess  and  manage  overall  project 
risks  for  the  duration  of  the  project,  and  second,  to  assess  and  manage 
risks  associated  with  the  performance  of  the  supplier.  As  the  acquisition 
progresses  to  the  selection  of  a  supplier,  the  risk  specific  to  the 
supplier’s  technical  and  management  approach  becomes  important  to 
the  success  of  the  acquisition,  [acqj 

The  acquirer  applies  Integrated  Project  Management  practices  to 
establish  and  manage  the  project  and  the  involvement  of  the  relevant 
stakeholders  according  to  an  integrated  and  defined  process  that  is 
tailored  from  the  organization’s  set  of  standard  processes.  A  repeatable 
Decision  Analysis  and  Resolution  process  is  important  for  an  acquirer, 
both  while  making  the  critical  decisions  that  define  and  guide  the 
acquisition  process  and  later  when  critical  decisions  are  made  with  the 
selected  supplier,  [acq] 

Acquisition  Requirements  Development  focuses  on  specifying  customer 
and  contractual  requirements  that  express  customer  value.  The 
acquirer  uses  Acquisition  Validation  processes  to  ensure  that  the 
products  or  services  received  from  the  supplier  will  fulfill  the  relevant 
stakeholders’  intentions  and  needs,  [acqj 

The  acquirer  provides  design  constraints  to  the  supplier.  The  product  or 
service  are  designed  and  implemented  by  the  supplier  consistent  with 
the  acquirer’s  design  constraints.  Acquisition  Technical  Solution  covers 
developing  design  constraints  and  verifying  the  technical  solution  of  the 
supplier.  The  acquirer  applies  Acquisition  Verification  processes  to 
address  whether  the  acquired  product,  intermediate  acquirer  work 
products,  and  supplier  deliverables  meet  their  contractual  requirements. 

[ACQ] 


Organizational  Process  Definition  focuses  on  establishing  and 
maintaining  a  usable  set  of  organizational  process  assets  and  work 
environment  standards.  The  acquirer’s  set  of  standard  processes  may 
also  describe  standard  interactions  with  suppliers.  Supplier  interactions 
are  typically  identified  in  terms  of  deliverables  expected  from  suppliers, 
acceptance  criteria  applicable  to  those  deliverables,  standards  (e.g., 
architecture  and  technology  standards),  and  standard  milestone  and 
progress  reviews,  [acq] 

The  acquirer  defines  in  the  supplier  agreement  how  changes  to 
organizational  process  assets  that  impact  the  supplier  (e.g.,  standard 
supplier  deliverables,  acceptance  criteria)  have  to  be  deployed.  The 
acquirer  encourages  participation  of  suppliers  in  process  improvement 
activities  (Organizational  Process  Focus).  Suppliers  may  be  involved  in 
developing  the  process  action  plans  if  the  processes  that  define 
interfaces  between  acquirer  and  supplier  are  targeted  for  improvement. 

[ACQ] 
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The  purpose  of  Organizational  Training  is  to  develop  the  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently,  [acq] 


Maturity  Level  4:  Quantitatively  Managed 


At  maturity  level  4,  acquirers  control  variation  in  their  results  through 
quantitative  management.  That  is,  acquirers  examine  the  business 
system  being  used  to  meet  the  needs  of  the  end  customer,  identifying 
constraints  that  significantly  impede  overall  business  performance. 
These  constraints  are  understood  using  statistical  and  other  quantitative 
techniques  so  that  an  acquirer  can  make  the  appropriate  process 
refinements  including  adjustments  to  its  supplier  interactions  to  better 
achieve  business  objectives.  Focusing  on  these  critical  constraints,  the 
acquirer  can  use  process  performance  models  to  predict  how  to  best 
maximize  the  flow  of  work  through  the  project  and/or  the  organization. 

[ACQ] 


Specific  measures  of  process  performance  are  collected  and 
statistically  analyzed.  When  selecting  the  processes  or  subprocesses 
for  analyses,  it  is  critical  to  understand  the  relationships  between 
different  processes  and  subprocesses  and  their  impact  on  the 
acquirer’s  and  supplier’s  performance  relative  to  delivering  the  product 
specified  by  the  customer.  Such  an  approach  will  help  ensure  that 
quantitative  and  statistical  management  is  applied  to  where  it  will  have 
the  most  overall  value  to  the  business.  Supplier  process  performance  is 
analyzed  as  it  interfaces  with  acquirer  processes,  through  data  and 
measures  submitted  by  the  supplier.  Performance  models  are  used  to 
set  performance  objectives  for  the  suppliers,  and  to  help  suppliers 
achieve  these  objectives,  [acq] 

A  critical  distinction  between  maturity  levels  3  and  4  is  the  predictability 
of  process  performance.  At  maturity  level  4,  the  performance  of 
processes  is  controlled  using  statistical  and  other  quantitative 
techniques,  and  is  quantitatively  predictable.  At  maturity  level  3, 
processes  are  typically  only  qualitatively  predictable. 


Maturity  Level  5:  Optimizing 


At  maturity  level  5,  an  organization  continually  improves  its  processes 
based  on  a  quantitative  understanding  of  the  common  causes  of 
variation  inherent  in  processes.  Maturity  level  5  focuses  on  continually 
improving  process  performance  through  incremental  and  innovative 
process  and  technological  improvements  that  enhance  the  acquirer’s 
and  its  suppliers’  ability  to  meet  the  acquirer’s  quality  and  process- 
performance  objectives,  [acq] 
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Quantitative  process-improvement  objectives  for  the  organization  are 
established,  continually  revised  to  reflect  changing  business  objectives, 
and  used  as  criteria  in  managing  process  improvement.  The  effects  of 
deployed  process  improvements  are  measured  and  evaluated  against 
the  quantitative  process-improvement  objectives.  Both  the  defined 
processes  and  the  organization’s  set  of  standard  processes  are  targets 
of  measurable  improvement  activities. 

The  acquirer  typically  achieves  its  quality  and  performance  objectives 
through  coordination  with  its  suppliers.  The  acquirer  typically  focuses  on 
capabilities  differentiation  along  with  collaborative  supplier 
management.  Achievement  of  these  objectives  also  depends  on  being 
able  to  effectively  evaluate  and  deploy  proposed  improvements  to  the 
processes  and  technologies.  All  members  of  the  acquirer-supplier 
network  participate  in  the  acquirer’s  process-  and  technology- 
improvement  activities.  This  participation  can  be  facilitated  if  suppliers 
are  willing  to  open  up  their  processes  for  inspection  to  the  acquirer  and 
other  suppliers  of  the  acquirer.  Their  process  improvement  proposals 
are  systematically  gathered  and  addressed,  [acq] 

A  critical  distinction  between  maturity  levels  4  and  5  is  the  type  of 
process  variation  addressed.  At  maturity  level  4,  the  organization  is 
concerned  with  addressing  special  causes  of  process  variation  and 
providing  statistical  predictability  of  the  results.  Although  processes  may 
produce  predictable  results,  the  results  may  be  insufficient  to  achieve 
the  established  objectives.  At  maturity  level  5,  the  organization  is 
concerned  with  addressing  common  causes  of  process  variation  and 
changing  the  process  (to  shift  the  mean  of  the  process  performance  or 
reduce  the  inherent  process  variation  experienced)  to  improve  process 
performance  and  to  achieve  the  established  quantitative  process- 
improvement  objectives. 


Relating  the  Two  Representations 


The  continuous  representation  enables  the  organization  or  projects  to 
choose  the  focus  of  its  process  improvement  efforts  by  choosing  those 
process  areas,  or  sets  of  interrelated  process  areas,  that  best  benefit 
the  acquirer  and  its  business  objectives.  Once  you  select  the  process 
areas,  you  must  also  select  how  much  you  would  like  to  mature  the 
processes  associated  with  those  process  areas  (i.e. ,  select  the 
appropriate  capability  level).  This  selection  is  typically  described 
through  a  target  profile.  A  target  profile  defines  all  of  the  process  areas 
to  be  addressed  and  the  targeted  capability  level  for  each.  This  profile 
then  governs  which  goals  and  practices  the  organization  will  address  in 
its  process-improvement  efforts,  [acq] 


28 


About  CMMI 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Organizations  that  target  capability  levels  higher  than  1  will  concentrate 
on  the  institutionalization  of  the  selected  processes  in  the  organization 
by  implementing  the  associated  generic  goals  and  practices.  Target 
staging  is  a  sequence  of  target  profiles  that  describes  the  path  of 
process  improvement  to  be  followed  by  the  organization.  When  building 
target  profiles,  the  organization  should  pay  attention  to  the 
dependencies  between  generic  practices  and  process  areas.  If  a 
generic  practice  depends  on  a  certain  process  area,  either  to  carry  out 
the  generic  practice  or  to  provide  a  prerequisite  product,  the  generic 
practice  may  be  much  less  effective  when  the  process  area  is  not 
implemented,  [acq] 


The  staged  representation  enables  the  organization  or  projects  to  use 
designated  sets  of  process  areas  to  follow  a  defined  improvement  path 
or  maturity  levels  for  an  acquirer.  The  staged  representation  provides  a 
predetermined  path  of  improvement  from  maturity  level  1  to  maturity 
level  5.  As  acquirers  improve  they  may  follow  different  improvement 
approaches,  [acqj 


Equivalent  staging  enables  an  organization  using  the  continuous 
representation  for  an  appraisal  to  convert  a  capability  level  profile  to  the 
associated  maturity  level  rating.  The  most  effective  way  to  depict 
equivalent  staging  is  to  provide  a  sequence  of  target  profiles,  each  of 
which  is  equivalent  to  a  maturity  level  rating  of  the  staged 
representation,  [acqj 

The  following  rules  summarize  equivalent  staging: 

•  To  achieve  maturity  level  2,  all  process  areas  assigned  to  maturity 
level  2  must  achieve  capability  level  2  or  higher. 

•  To  achieve  maturity  level  3,  all  process  areas  assigned  to  maturity 
levels  2  and  3  must  achieve  capability  level  3  or  higher. 

•  To  achieve  maturity  level  4,  all  process  areas  assigned  to  maturity 
levels  2,  3,  and  4  must  achieve  capability  level  3  or  higher. 

•  To  achieve  maturity  level  5,  all  process  areas  must  achieve 
capability  level  3  or  higher. 


Process  Area  Categories 


While  all  process  areas  have  dependencies  with  all  other  process 
areas,  some  process  areas  have  similar  or  closely-related  purposes. 
This  similarity  in  purpose  is  a  basis  for  categorizing  the  process  areas 
into  process  area  categories,  [acq] 

Process  areas  can  be  grouped  into  four  categories:  [acq] 

•  Process  Management 
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•  Project  Management 

•  Acquisition 

•  Support 

Understanding  these  process  area  categories  will  help  users  of  the 
initial  draft  CMMI-ACQ  recognize  closely-allied  process  areas.  Users 
are  encouraged  to  take  the  time  needed  to  understand  the 
interdependencies  within  and  across  process  area  categories  when 
planning  organizational  process  improvement,  [acq] 

Process  Management  process  areas  contain  the  cross-project  activities 
related  to  defining,  planning,  deploying,  implementing,  monitoring, 
controlling,  appraising,  measuring,  and  improving  processes,  [acq] 

The  Process  Management  process  areas  are  as  follows:  [acqj 

•  Organizational  Innovation  and  Deployment 

•  Organizational  Process  Definition 

•  Organizational  Process  Focus 

•  Organizational  Process  Performance 

•  Organizational  Training 

Project  Management  process  areas  cover  the  project  management 
activities  related  to  planning,  monitoring,  and  controlling  the  project,  [acq] 

The  Project  Management  process  areas  are  as  follows:  [acqj 

•  Integrated  Project  Management 

•  Project  Monitoring  and  Control 

•  Project  Planning 

•  Quantitative  Project  Management 

•  Requirements  Management8 

•  Risk  Management 

Acquisition  process  areas  cover  the  activities  related  to  the  acquisition 
of  products  and  services  from  suppliers,  [acq] 

The  Acquisition  process  areas  are  as  follows:  [acq] 

•  Acquisition  Management 

•  Acquisition  Requirements  Development 

•  Acquisition  Technical  Solution 

s  The  Requirements  Management  process  area  is  instead  categorized  as  belonging  to  the  Engineering  process 
area  category  within  the  CMMI  for  Development,  vl.2.  As  there  is  no  such  process  area  category  in  the  initial 
draft  CMMI-ACQ,  it  is  categorized  as  belonging  to  the  Project  Management  process  area  category. 
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•  Acquisition  Validation 

•  Acquisition  Verification 

•  Solicitation  and  Supplier  Agreement  Development 

Support  process  areas  address  processes  that  are  used  in  the  context 
of  performing  other  processes.  In  general,  the  Support  process  areas 
address  processes  that  are  targeted  toward  the  project,  and  may 
address  processes  that  apply  more  generally  to  the  organization.  For 
example,  Process  and  Product  Quality  Assurance  can  be  used  with  all 
the  process  areas  to  provide  an  objective  evaluation  of  the  processes 
and  work  products  described  in  these  process  areas,  [acq] 

The  Support  process  areas  of  CMMI  are  as  follows:  [acq] 

•  Causal  Analysis  and  Resolution 

•  Configuration  Management 

•  Decision  Analysis  and  Resolution 

•  Measurement  and  Analysis 

•  Process  and  Product  Quality  Assurance 
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4  Using  CMMI  Models 


The  complexity  of  today’s  products  demands  an  integrated  view  of  how 
organizations  do  business.  CMMI  can  reduce  the  cost  of  process 
improvement  across  enterprises  that  depend  on  multiple  functions  or 
groups  to  produce  products  and  services. 

To  achieve  this  integrated  view,  the  CMMI  Framework  includes 
common  terminology,  common  model  components,  common  appraisal 
methods,  and  common  training  materials.  This  chapter  describes  how 
organizations  can  use  the  CMMI  Product  Suite  for  not  only  improving 
their  quality,  reducing  their  costs,  and  optimizing  their  schedules,  but 
also  gauging  how  well  their  process  improvement  program  is  doing. 


Adopting  CMMI 


Research  has  shown  that  the  most  powerful  initial  step  to  process 
improvement  is  to  build  strong  organizational  support  through  strong 
senior  management  sponsorship.  To  gain  senior  management 
sponsorship,  it  is  often  beneficial  to  expose  senior  management  to  the 
performance  results  experienced  by  others  who  have  used  CMMI  to 
improve  their  processes. 

For  more  information  about  CMMI  performance  results,  see  the  SEI 
Web  site  at  http://www.sei.cmu.edu/cmmi/results.html  [SEI  3], 

The  senior  manager,  once  committed  as  the  process  improvement 
sponsor,  must  be  actively  involved  in  the  CMMI-based  process 
improvement  effort.  Activities  performed  by  the  senior  management 
sponsor  include,  but  are  not  limited  to  the  following: 

•  influence  the  organization  to  adopt  CMMI 

•  choose  the  best  people  to  manage  the  process  improvement  effort 

•  monitor  the  process  improvement  effort  personally 

•  be  a  visible  advocate  and  spokesperson  for  the  process 
improvement  effort 

•  ensure  that  adequate  resources  are  available  to  enable  the  process 
improvement  effort  to  be  successful. 
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Given  sufficient  senior  management  sponsorship,  the  next  step  is 
establishing  a  strong,  technically  competent  process  group  that 
represents  relevant  stakeholders  to  guide  process-improvement  efforts. 

For  an  organization  with  a  mission  to  develop  software-intensive 
systems,  the  process  group  might  include  engineers  representing  the 
different  technical  disciplines  across  the  organization,  and  other 
selected  members  based  on  the  business  needs  driving  improvement. 
For  example,  a  systems  administrator  may  focus  on  information- 
technology  support,  whereas  a  marketing  representative  may  focus  on 
integrating  customers’  needs.  Both  members  could  make  powerful 
contributions  to  the  process  group. 

Once  your  organization  has  decided  to  adopt  CMMI,  planning  can  begin 
with  an  improvement  approach  such  as  the  IDEALSM  (Initiating, 
Diagnosing,  Establishing,  Acting,  Learning)  model  [SEI  2],  For  more 
information  about  the  IDEAL  model,  see  the  Software  Engineering 
Institute  Web  site  at:  http://www.sei.cmu.edu/ideal/ideal.html  [SEI  1] 


Your  Process  Improvement  Program 


Use  the  CMMI  Product  Suite  to  help  establish  your  organization’s 
process  improvement  program.  Using  the  product  suite  for  this  purpose 
can  be  a  relatively  informal  process  that  involves  understanding  and 
applying  CMMI  best  practices  to  your  organization.  Or,  it  can  be  a 
formal  process  that  involves  extensive  training,  creation  of  a  process 
improvement  infrastructure,  appraisals,  and  more. 


Selections  That  Influence  Your  Program 


There  are  three  selections  you  must  make  to  apply  CMMI  to  your 
organization  for  process  improvement:  (1 )  select  the  part  of  the 
organization,  (2)  select  the  model  (3)  select  a  representation. 

Selecting  the  projects  to  be  involved  in  your  process  improvement 
program  is  critical.  If  you  select  a  group  that  is  too  large,  it  may  be  too 
much  for  the  initial  improvement  effort.  The  selection  should  also 
consider  how  homogeneous  the  group  is  (i.e.,  are  they  all  software 
engineers,  do  they  all  work  on  the  same  product  or  business  line). 

Selecting  the  model  to  be  used  depends  on  the  areas  your  organization 
is  interested  in  improving.  Not  only  must  you  select  a  constellation  (e.g., 
Development,  Acquisition,  or  Services),  you  must  also  decide  whether 
to  include  any  additions  (e.g.,  IPPD). 
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Selecting  the  representation  to  be  used  has  some  guidelines  because 
of  how  CMMI  models  are  built.  If  your  organization  likes  the  idea  of 
maturity  levels  and  the  staged  representation,  your  improvement 
roadmap  is  already  defined.  If  your  organization  likes  the  continuous 
representation,  you  can  select  nearly  any  process  area  or  group  of 
process  areas  to  guide  improvement,  although  dependencies  among 
process  areas  should  be  considered  when  making  such  a  selection. 

As  the  process  improvement  plans  and  activities  progress,  other 
important  selections  must  be  made,  including:  (1)  which  appraisal 
method  should  be  used,  (2)  which  projects  should  be  appraised,  (3) 
how  should  training  for  personnel  be  secured,  (4)  which  personnel 
should  be  trained. 


CMMI  Models 


CMMI  models  describe  what  have  been  determined  to  be  best  practices 
that  organizations  have  found  to  be  productive  and  useful  to  achieving 
business  objectives.  Regardless  of  your  type  of  organization,  to  apply 
CMMI  practices,  you  must  use  professional  judgment  to  interpret  them 
for  your  situation,  needs,  and  business  objectives.  Although  process 
areas  depict  the  characteristics  of  an  organization  committed  to  process 
improvement,  you  must  interpret  the  process  areas  using  an  in-depth 
knowledge  of  CMMI,  your  organization,  the  business  environment,  and 
the  specific  circumstances  involved. 

As  you  begin  using  a  CMMI  model  for  improving  your  organization’s 
processes,  map  your  real-world  processes  to  a  CMMI  model’s  process 
areas.  This  mapping  enables  you  to  initially  judge  and  later  track  your 
organization’s  level  of  conformance  to  the  CMMI  model  you  are  using 
and  to  identify  opportunities  for  improvement. 

To  interpret  practices,  it  is  important  to  consider  the  overall  context  in 
which  these  practices  are  used  and  to  determine  how  well  the  practices 
satisfy  the  goals  of  a  process  area  in  that  context.  CMMI  models  do  not 
explicitly  prescribe  nor  imply  particular  processes  that  are  right  for  any 
organization  or  project.  Instead,  CMMI  describes  minimal  criteria 
necessary  to  plan  and  implement  processes  selected  by  the 
organization  for  improvement  based  on  business  objectives. 

CMMI  practices  purposely  use  nonspecific  phrases  such  as  “relevant 
stakeholders,”  “as  appropriate,”  and  “as  necessary”  to  accommodate 
the  needs  of  different  organizations  and  projects.  The  specific  needs  of 
a  project  may  also  differ  at  various  points  during  its  life. 
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Using  CMMI  Appraisals 


Many  organizations  find  value  in  measuring  their  progress  by 
conducting  an  appraisal  and  thus  earning  a  maturity  level  rating  or  a 
capability  level  achievement  profile.  These  appraisals  are  typically 
conducted  for  one  or  more  of  the  following  reasons: 

•  To  determine  how  well  the  organization’s  processes  compare  to 
CMMI  best  practices  and  identify  areas  where  improvement  can  be 
made 

•  To  inform  external  customers  and  suppliers  about  how  well  the 
organization’s  processes  compare  to  CMMI  best  practices 

•  To  meet  the  contract  requirements  of  one  or  more  customers 

Appraisals  or  organizations  using  a  CMMI  model  must  conform  to  the 
requirements  defined  in  the  Appraisal  Requirements  for  CMMI  (ARC) 
document.  These  appraisals  focus  on  identifying  improvement 
opportunities  and  comparing  the  organization’s  processes  to  CMMI  best 
practices.  Appraisal  teams  use  a  CMMI  model  and  ARC-conformant 
appraisal  method  to  guide  their  evaluation  of  the  organization  as  well  as 
how  they  report  their  conclusions.  The  appraisal  results  are  then  used 
(by  a  process  group,  for  example)  to  plan  improvements  for  the 
organization.  [Ahern  2005], 

Appraisal  Requirements  for  CMMI 


The  Appraisal  Requirements  for  CMMI  (ARC)  document  describes  the 
requirements  for  several  types  of  appraisals.  A  full  benchmarking  class 
of  appraisal  is  defined  as  a  Class  A  appraisal.  Less  formal  methods  are 
defined  as  Class  B  or  C  methods.  The  ARC  document  was  designed  to 
help  improve  consistency  across  appraisal  methods,  and  to  help 
appraisal  method  developers,  sponsors,  and  users  understand  the 
tradeoffs  associated  with  various  methods.9 

Depending  on  the  purpose  of  the  appraisal  and  the  nature  of  the 
circumstances,  one  class  may  be  preferred  over  the  others.  Sometimes 
self-assessments,  initial  appraisals,  quick-look  or  mini-appraisals, 
incremental  appraisals,  or  external  appraisals  are  appropriate;  whereas 
at  other  times  a  formal  benchmarking  appraisal  is  appropriate. 

A  particular  appraisal  method  is  declared  an  ARC  Class  A,  B,  or  C 
appraisal  method  based  on  the  sets  of  ARC  requirements  that  the 
method  developer  has  addressed  when  designing  the  method. 

More  information  about  the  ARC  is  available  on  the  Software 
Engineering  Institute’s  Web  site  at 
http://www.sei.cmu.edu/cmmi/appraisals/appraisals.html. 


9  See  the  forthcoming  Appraisal  Requirements  for  CMMI. 
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SCAMPI  Appraisal  Methods 


The  SCAMPI  appraisal  methods  are  the  generally  accepted  methods 
used  for  conducting  appraisals  using  CMMI  models.  The  SCAMPI 
Method  Definition  Document  (MDD)  defines  rules  for  ensuring  the 
consistency  of  appraisal  ratings.  For  benchmarking  against  other 
organizations,  appraisals  must  ensure  consistent  ratings.  The 
achievement  of  a  specific  maturity  level  or  the  satisfaction  of  a  process 
area  must  mean  the  same  thing  for  different  appraised  organizations. 

The  SCAMPI  family  of  appraisals  includes  Class  A,  B,  and  C  appraisal 
methods.  SCAMPI  A  is  the  most  rigorous  method  and  the  only  method 
that  can  result  in  a  rating.  SCAMPI  B  provides  options  in  model  scope, 
but  the  characterization  of  practices  is  fixed  to  one  scale  and  is 
performed  on  implemented  practices.  SCAMPI  C  provides  a  wide  range 
of  options,  including  characterization  of  planned  approaches  to  process 
implementation  according  to  a  scale  defined  by  the  user. 

More  information  about  SCAMPI  methods  is  available  on  the  Software 
Engineering  Institute  Web  site  at  the  following  URL: 
http://www.sei.cmu.edu/cmmi/appraisals/appraisals.html.10 


Appraisal  Considerations 


Choices  that  affect  a  CMMI-based  appraisal  include  the  following: 

•  Establishing  the  appraisal  scope,  including  the  organizational  unit  to 
be  appraised,  the  CMMI  process  areas  to  be  investigated,  and  the 
maturity  level  or  capability  level(s)  to  be  appraised 

•  Selecting  the  appraisal  method 

•  Selecting  the  appraisal  team  members 

•  Selecting  appraisal  participants  from  the  appraisal  entities  to  be 
interviewed 

•  Establishing  appraisal  outputs  (e.g.,  ratings,  instantiation-specific 
findings) 

•  Establishing  appraisal  constraints  (e.g.,  time  spent  on  site) 

The  SCAMPI  Method  Definition  Document  allows  the  selection  of 

predefined  options  for  use  in  an  appraisal.  These  appraisal  options  are 

designed  to  help  organizations  align  CMMI  with  their  business  needs 

and  objectives. 


10  See  the  forthcoming  Standard  CMMI  Appraisal  Method  for  Process  Improvement  Method  Definition 
Document. 
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Documentation  of  CMMI  appraisal  plans  and  results  must  always 
include  a  description  of  the  appraisal  options,  model  scope,  and 
organizational  scope  selected.  This  documentation  confirms  whether  an 
appraisal  meets  the  requirements  for  benchmarking. 

For  organizations  that  wish  to  appraise  multiple  functions  or  groups, 
CMMI’s  integrated  approach  enables  some  economy  of  scale  in  model 
and  appraisal  training.  One  appraisal  method  can  provide  separate  or 
combined  results  for  multiple  functions. 

The  appraisal  principles  for  the  CMMI  Product  Suite11  remain  the  same 
as  those  used  in  appraisals  for  other  process-improvement  models. 
Those  principles  are  listed  below: 

•  Senior  management  sponsorship12 

•  A  focus  on  the  organization’s  business  objectives 

•  Confidentiality  for  interviewees 

•  Use  of  a  documented  appraisal  method 

•  Use  of  a  process  reference  model  (e.g.,  a  CMMI  model)  as  a  base 

•  A  collaborative  team  approach 

•  A  focus  on  actions  for  process  improvement 


CMMI-Related  Training 


Whether  your  organization  is  new  to  process  improvement  or  is  already 
familiar  with  process-improvement  models,  training  is  a  key  element  in 
the  ability  of  organizations  to  adopt  CMMI.  An  initial  set  of  courses  is 
provided  by  the  SEI  and  its  Partners13,  but  your  organization  may  wish 
to  supplement  these  courses  with  internal  instruction.  This  approach 
allows  your  organization  to  focus  on  the  areas  that  provide  the  greatest 
business  value. 


1 1  See  the  glossary  for  the  definition  of  CMMI  Product  Suite. 

12  Experience  has  shown  that  the  most  critical  factor  influencing  successful  process  improvement  and  appraisals 
is  senior  management  sponsorship. 

13  Courses  covering  acquisition  will  gradually  become  available;  initial  training  will  be  available  to  support 
using  the  initial  draft  CMMI-ACQ. 
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Current  information  about  CMMI-related  training  is  available  on  the 
Software  Engineering  Institute  Web  site  at: 
http://www.sei.cmu.edu/cmmi/training/training.html. 
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GENERIC  GOALS  AND  PRACTICES 


Overview 


This  chapter  describes,  in  detail,  all  the  generic  goals  and  generic 
practices — model  components  that  directly  address  process 
institutionalization. 

The  text  of  the  generic  goals  and  generic  practices  is  not  repeated  in 
the  process  areas.  As  you  address  each  process  area,  refer  to  this 
chapter  for  the  details  of  all  generic  practices,  [acq] 


Process  Institutionalization 


“Institutionalization”  is  an  important  concept  in  process  improvement. 
When  mentioned  in  the  generic  goal  and  generic  practice  descriptions, 
institutionalization  implies  that  the  process  is  ingrained  in  the  way  the 
work  is  performed  and  there  is  commitment  and  consistency  to 
performing  the  process. 

An  institutionalized  process  is  more  likely  to  be  retained  during  times  of 
stress.  When  the  requirements  and  objectives  for  the  process  change, 
however,  the  implementation  of  the  process  may  also  need  to  change 
to  ensure  that  it  remains  effective.  The  generic  practices  describe 
activities  that  address  these  aspects  of  institutionalization. 

The  degree  of  institutionalization  is  embodied  in  the  generic  goals  and 
expressed  in  the  names  of  the  processes  associated  with  each  goal  as 
indicated  in  Table  5.1 . 

Table  5. 1:  Generic  Goals  and  Process  Names 


Generic  Goal 

Progression  of  Processes 

GG  1 

Performed  process 

GG  2 

Managed  process 

GG  3 

Defined  process 

GG  4 

Quantitatively  managed  process 

GG  5 

Optimizing  process 

The  progression  of  process  institutionalization  is  described  in  the 
following  descriptions  of  each  process. 
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Performed  Process 


A  performed  process  is  a  process  that  accomplishes  the  work 
necessary  to  produce  work  products.  The  specific  goals  of  the  process 
area  are  satisfied. 

Managed  Process 


A  managed  process  is  a  performed  process  that  is  planned  and 
executed  in  accordance  with  policy;  employs  skilled  people  who  have 
adequate  resources  to  produce  controlled  outputs;  involves  relevant 
stakeholders;  is  monitored,  controlled,  and  reviewed;  and  is  evaluated 
for  adherence  to  its  process  description.  The  process  may  be 
instantiated  by  a  project,  group,  or  organizational  function.  Management 
of  the  process  is  concerned  with  institutionalization  and  the 
achievement  of  other  specific  objectives  established  for  the  process, 
such  as  cost,  schedule,  and  quality  objectives.  The  control  provided  by 
a  managed  process  helps  ensure  that  the  established  process  is 
retained  during  times  of  stress. 

The  requirements  and  objectives  for  the  process  are  established.  The 
status  of  the  work  products  and  delivery  of  the  services  are  visible  to 
management  at  defined  points  (e.g.,  at  major  milestones  and 
completion  of  major  tasks).  Commitments  are  established  among  those 
performing  the  work  and  the  relevant  stakeholders  and  are  revised  as 
necessary.  Work  products  are  reviewed  with  relevant  stakeholders  and 
are  controlled.  The  work  products  and  services  satisfy  their  specified 
requirements. 

A  critical  distinction  between  a  performed  process  and  a  managed 
process  is  the  extent  to  which  the  process  is  managed.  A  managed 
process  is  planned  (the  plan  may  be  part  of  a  more  encompassing  plan) 
and  the  performance  of  the  process  is  managed  against  the  plan. 
Corrective  actions  are  taken  when  the  actual  results  and  performance 
deviate  significantly  from  the  plan.  A  managed  process  achieves  the 
objectives  of  the  plan  and  is  institutionalized  for  consistent  performance. 

Defined  Process 


A  defined  process  is  a  managed  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description;  and 
contributes  work  products,  measures,  and  other  process  improvement 
information  to  the  organizational  process  assets. 
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The  organizational  process  assets  are  artifacts  that  relate  to  describing, 
implementing,  and  improving  processes.  These  artifacts  are  assets 
because  they  are  developed  or  acquired  to  meet  the  business 
objectives  of  the  organization,  and  they  represent  investments  by  the 
organization  that  are  expected  to  provide  current  and  future  business 
value. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the 
defined  process,  are  established  and  improved  overtime.  Standard 
processes  describe  the  fundamental  process  elements  that  are 
expected  in  the  defined  processes.  Standard  processes  also  describe 
the  relationships  (e.g.,  the  ordering  and  the  interfaces)  among  these 
process  elements.  The  organization-level  infrastructure  to  support 
current  and  future  use  of  the  organization’s  set  of  standard  processes  is 
established  and  improved  over  time.  (See  the  definition  of  “standard 
process”  in  the  glossary.) 

A  project’s  defined  process  provides  a  basis  for  planning,  performing, 
and  improving  the  project’s  tasks  and  activities.  A  project  may  have 
more  than  one  defined  process  (e.g.,  one  for  developing  the  product 
and  another  for  testing  the  product). 

A  defined  process  clearly  states  the  following: 

•  Purpose 

•  Inputs 

•  Entry  criteria 

•  Activities 

•  Roles 

•  Measures 

•  Verification  steps 

•  Outputs 

•  Exit  criteria 

A  critical  distinction  between  a  managed  process  and  a  defined  process 
is  the  scope  of  application  of  the  process  descriptions,  standards,  and 
procedures.  Fora  managed  process,  the  process  descriptions, 
standards,  and  procedures  are  applicable  to  a  particular  project,  group, 
or  organizational  function.  As  a  result,  the  managed  processes  of  two 
projects  in  one  organization  may  be  different. 
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Another  critical  distinction  is  that  a  defined  process  is  described  in  more 
detail  and  performed  more  rigorously  than  a  managed  process.  This 
means  that  improvement  information  is  easier  to  understand,  analyze, 
and  use.  Finally,  management  of  the  defined  process  is  based  on  the 
additional  insight  provided  by  an  understanding  of  the  interrelationships 
of  the  process  activities  and  detailed  measures  of  the  process,  its  work 
products,  and  its  services. 

Quantitatively  Managed  Process 


A  quantitatively  managed  process  is  a  defined  process  that  is  controlled 
using  statistical  and  other  quantitative  techniques.  The  product  quality, 
service  quality,  and  process  performance  attributes  are  measurable  and 
controlled  throughout  the  project. 

Quantitative  objectives  are  established  based  on  the  capability  of  the 
organization’s  set  of  standard  processes;  the  organization’s  business 
objectives;  and  the  needs  of  the  customer,  end  users,  organization,  and 
process  implementers,  subject  to  available  resources.  The  people 
performing  the  process  are  directly  involved  in  quantitatively  managing 
the  process. 

Quantitative  management  is  performed  on  the  overall  set  of  processes 
that  produces  a  product  or  provides  a  service.  The  subprocesses  that 
are  significant  contributors  to  overall  process  performance  are 
statistically  managed.  For  these  selected  subprocesses,  detailed 
measures  of  process  performance  are  collected  and  statistically 
analyzed.  Special  causes  of  process  variation  are  identified  and,  where 
appropriate,  the  source  of  the  special  cause  is  addressed  to  prevent  its 
recurrence. 

The  quality  and  process  performance  measures  are  incorporated  into 
the  organization’s  measurement  repository  to  support  future  fact-based 
decision  making. 

Activities  for  quantitatively  managing  the  performance  of  a  process 
include  the  following: 

•  Identifying  the  subprocesses  that  are  to  be  brought  under  statistical 
management 

•  Identifying  and  measuring  product  and  process  attributes  that  are 
important  contributors  to  quality  and  process  performance 

•  Identifying  and  addressing  special  causes  of  subprocess  variations 
(based  on  the  selected  product  and  process  attributes  and 
subprocesses  selected  for  statistical  management) 

•  Managing  each  of  the  selected  subprocesses,  with  the  objective  of 
bringing  their  performance  within  natural  bounds  (i.e. ,  making  the 
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subprocess  performance  statistically  stable  and  predictable  based 
on  the  selected  product  and  process  attributes) 

•  Predicting  the  ability  of  the  process  to  satisfy  established 
quantitative  quality  and  process-performance  objectives 

•  Taking  appropriate  corrective  actions  when  it  is  determined  that  the 
established  quantitative  quality  and  process-performance  objectives 
will  not  be  satisfied 

These  corrective  actions  include  changing  the  objectives  or  ensuring 
that  relevant  stakeholders  have  a  quantitative  understanding  of,  and 
have  agreed  to,  the  performance  shortfall. 

A  critical  distinction  between  a  defined  process  and  a  quantitatively 
managed  process  is  the  predictability  of  the  process  performance.  The 
term  “quantitatively  managed”  implies  using  appropriate  statistical  and 
other  quantitative  techniques  to  manage  the  performance  of  one  or 
more  critical  subprocesses  so  that  the  performance  of  the  process  can 
be  predicted.  A  defined  process  provides  only  qualitative  predictability. 

Optimizing  Process 


An  optimizing  process  is  a  quantitatively  managed  process  that  is 
changed  and  adapted  to  meet  relevant  current  and  projected  business 
objectives.  An  optimizing  process  focuses  on  continually  improving 
process  performance  through  both  incremental  and  innovative 
technological  improvements.  Process  improvements  that  address 
common  causes  of  process  variation,  root  causes  of  defects  and  other 
problems,  and  those  that  would  measurably  improve  the  organization’s 
processes  are  identified,  evaluated,  and  deployed  as  appropriate. 

These  improvements  are  selected  based  on  a  quantitative 
understanding  of  their  expected  contribution  to  achieving  the 
organization’s  process-improvement  objectives  versus  the  cost  and 
impact  to  the  organization.  The  process  performance  of  the 
organization’s  processes  is  continually  improved. 

Selected  incremental  and  innovative  technological  process 
improvements  are  systematically  managed  and  deployed  into  the 
organization.  The  effects  of  the  deployed  process  improvements  are 
measured  and  evaluated  against  the  quantitative  process-improvement 
objectives. 

In  a  process  that  is  optimized,  common  causes  of  process  variation  are 
addressed  by  changing  the  process  in  a  way  that  will  shift  the  mean  or 
decrease  variation  when  the  process  is  restabilized.  These  changes  are 
intended  to  improve  process  performance  and  achieve  the 
organization’s  established  process-improvement  objectives. 
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A  critical  distinction  between  a  quantitatively  managed  process  and  an 
optimizing  process  is  that  the  optimizing  process  is  continuously 
improved  by  addressing  common  causes  of  process  variation.  A 
quantitatively  managed  process  is  concerned  with  addressing  special 
causes  of  process  variation  and  providing  statistical  predictability  of  the 
results.  Although  the  process  may  produce  predictable  results,  the 
results  may  be  insufficient  to  achieve  the  organization’s  process- 
improvement  objectives. 

Relationships  among  Processes 


The  generic  goals  evolve  so  that  each  goal  provides  a  foundation  for 
the  next.  Therefore  the  following  conclusions  can  be  made: 

•  A  managed  process  is  a  performed  process. 

•  A  defined  process  is  a  managed  process. 

•  A  quantitatively  managed  process  is  a  defined  process. 

•  An  optimizing  process  is  a  quantitatively  managed  process. 

Thus,  applied  sequentially  and  in  order,  the  generic  goals  describe  a 
process  that  is  increasingly  institutionalized,  from  a  performed  process 
to  an  optimizing  process. 

Achieving  GG  1  for  a  process  area  is  equivalent  to  saying  you  achieve 
the  specific  goals  of  the  process  area. 

Achieving  GG  2  for  a  process  area  is  equivalent  to  saying  you  manage 
the  performance  of  processes  associated  with  the  process  area.  There 
is  a  policy  that  indicates  you  will  perform  it.  There  is  a  plan  for 
performing  it.  There  are  resources  provided,  responsibilities  assigned, 
training  on  how  to  perform  it,  selected  work  products  from  performing 
the  process  are  controlled,  and  so  on.  In  other  words,  the  process  is 
planned  and  monitored  just  like  any  project  or  support  activity. 

Achieving  GG  3  for  a  process  area  assumes  that  an  organizational 
standard  process  exists  that  can  be  tailored  to  result  in  the  process  you 
will  use.  Tailoring  might  result  in  making  no  changes  to  the  standard 
process.  In  other  words,  the  process  used  and  the  standard  process 
may  be  identical.  Using  the  standard  process  “as  is”  is  tailoring  because 
the  choice  is  made  that  no  further  modification  is  required. 

Each  process  area  describes  multiple  activities,  some  of  which  are 
repeatedly  performed.  You  may  need  to  tailor  the  way  one  of  these 
activities  is  performed  to  account  for  new  capabilities  or  circumstances. 
For  example,  you  may  have  a  standard  for  developing  or  obtaining 
organizational  training  that  does  not  consider  Web-based  training. 

When  preparing  to  develop  or  obtain  a  Web-based  course,  you  may 
need  to  tailor  that  standard  process  to  account  for  the  particular 
challenges  and  benefits  of  Web-based  training. 
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Achieving  GG  4  or  GG  5  for  a  process  area  is  conceptually  feasible  but 
may  not  be  economical  except,  perhaps,  in  situations  where  the  product 
domain  has  become  stable  for  an  extended  period  or  in  situations  in 
which  the  process  area  or  domain  is  a  critical  business  driver. 


Generic  Goals  and  Generic  Practices 


This  section  describes  all  of  the  generic  goals  and  generic  practices,  as 
well  as  their  associated  subpractices,  notes,  examples,  and  references. 
The  generic  goals  are  organized  in  numerical  order,  GG  1  through  GG 
5.  The  generic  practices  are  also  organized  in  numerical  order  under 
the  generic  goal  they  support. 

As  mentioned  earlier  in  this  chapter,  the  text  of  the  generic  practices  is 
not  repeated  in  the  process  areas;  the  text  for  each  generic  goal  and 
generic  practice  is  found  only  here,  [acq] 


GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of 
the  process  area  by  transforming  identifiable  input  work  products  to 
produce  identifiable  output  work  products. 


GP1.1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  process  area  to  develop 
work  products  and  provide  services  to  achieve  the  specific 
goals  of  the  process  area. 


The  purpose  of  this  generic  practice  is  to  produce  the  work  products 
and  deliver  the  services  that  are  expected  by  performing  the  process 
These  practices  may  be  done  informally,  without  following  a 
documented  process  description  or  plan.  The  rigor  with  which  these 
practices  are  performed  depends  on  the  individuals  managing  and 
performing  the  work  and  may  vary  considerably. 


GG  2  Institutionalize  a  Managed  Process 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning 
and  performing  the  process. 


The  purpose  of  this  generic  practice  is  to  define  the  organizational 
expectations  for  the  process  and  make  these  expectations  visible  to 
those  in  the  organization  who  are  affected.  In  general,  senior 
management  is  responsible  for  establishing  and  communicating  guiding 
principles,  direction,  and  expectations  for  the  organization. 
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Not  all  direction  from  senior  management  will  bear  the  label  “policy.” 
The  existence  of  appropriate  organizational  direction  is  the  expectation 
of  this  generic  practice,  regardless  of  what  it  is  called  or  how  it  is 
imparted. 

This  policy  establishes  organizational  expectations  for  planning  and 
performing  the  process;  including  not  only  the  elements  of  the  process 
addressed  directly  by  the  acquirer,  but  also  the  interactions  of  the 
acquirer  with  suppliers,  [acq] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process. 


The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to 
perform  the  process  and  to  achieve  the  established  objectives,  to 
prepare  a  plan  for  performing  the  process,  to  prepare  a  process 
description,  and  to  get  agreement  on  the  plan  from  relevant 
stakeholders. 

The  practical  implications  of  applying  a  generic  practice  vary  for  each 
process  area.  Consider  these  variances  as  they  relate  to  planning  the 
process. 

For  example,  the  planning  described  by  this  generic  practice  as  applied 
to  the  Project  Monitoring  and  Control  process  area  may  be  carried  out 
in  full  by  the  processes  associated  with  the  Project  Planning  process 
area.  However,  this  generic  practice  when  applied  to  the  Project 
Planning  process  area,  sets  an  expectation  that  the  project  planning 
process  itself  be  planned.  It  is  important  to  be  aware  of  the  extent  to 
which  this  generic  practice  may  either  reinforce  expectations  set 
elsewhere  in  CMMI  or  set  new  expectations  that  should  be  addressed. 

Establishing  a  plan  includes  documenting  the  plan  and  providing  a 
process  description.  Maintaining  the  plan  includes  changing  it,  as 
necessary,  in  response  to  either  corrective  actions  or  to  changes  in 
requirements  and  objectives  for  the  process. 

The  plan  for  performing  the  process  typically  includes  the  following: 

•  Process  description 

•  Standards  and  requirements  for  the  work  products  and  services  of 
the  process 

•  Specific  objectives  for  the  performance  of  the  process  (e.g.,  quality, 
time  scale,  cycle  time,  and  resource  usage) 

•  Dependencies  among  the  activities,  work  products,  and  services  of 
the  process 

•  Resources  (including  funding,  people,  and  tools)  needed  to  perform 
the  process 
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•  Assignment  of  responsibility  and  authority 

•  Training  needed  for  performing  and  supporting  the  process 

•  Work  products  to  be  controlled  and  the  level  of  control  to  be  applied 

•  Measurement  requirements  to  provide  insight  into  the  performance 
of  the  process,  its  work  products,  and  its  services 

•  Involvement  of  identified  stakeholders 

•  Activities  for  monitoring  and  controlling  the  process 

•  Objective  evaluation  activities  of  the  process 

•  Management  review  activities  for  the  process  and  the  work  products 

Subpractices 

1 .  Define  and  document  the  plan  for  performing  the  process. 

This  plan  may  be  a  stand-alone  document,  embedded  in  a  more  comprehensive 
document,  or  distributed  across  multiple  documents.  In  the  case  of  the  plan  being 
distributed  across  multiple  documents,  ensure  that  a  coherent  picture  of  who  does 
what  is  preserved.  Documents  may  be  hardcopy  or  softcopy. 

2.  Define  and  document  the  process  description. 

The  process  description,  which  includes  relevant  standards  and  procedures,  may 
be  included  as  part  of  the  plan  for  performing  the  process  or  may  be  included  in 
the  plan  by  reference. 

3.  Review  the  plan  with  relevant  stakeholders  and  get  their 
agreement. 

This  includes  reviewing  that  the  planned  process  satisfies  the  applicable  policies, 
plans,  requirements,  and  standards  to  provide  assurance  to  relevant 
stakeholders. 

4.  Revise  the  plan  as  necessary. 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  the  resources 
necessary  to  perform  the  process  as  defined  by  the  plan  are  available 
when  they  are  needed.  Resources  include  adequate  funding, 
appropriate  physical  facilities,  skilled  people,  and  appropriate  tools. 

The  interpretation  of  the  term  adequate  depends  on  many  factors  and 
can  change  overtime.  Inadequate  resources  may  be  addressed  by 
increasing  resources  or  by  removing  requirements,  constraints,  and 
commitments. 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of 
the  process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  there  is 
accountability  for  performing  the  process  and  achieving  the  specified 
results  throughout  the  life  of  the  process.  The  people  assigned  must 
have  the  appropriate  authority  to  perform  the  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in 
living  documents,  such  as  the  plan  for  performing  the  process.  Dynamic 
assignment  of  responsibility  is  another  legitimate  way  to  perform  this 
generic  practice,  as  long  as  the  assignment  and  acceptance  of 
responsibility  are  ensured  throughout  the  life  of  the  process. 

Subpractices 

1 .  Assign  overall  responsibility  and  authority  for  performing  the 
process. 

2.  Assign  responsibility  and  authority  for  performing  the  specific  tasks 
of  the  process. 

3.  Confirm  that  the  people  assigned  to  the  responsibilities  and 
authorities  understand  and  accept  them. 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  as 
needed. 


The  purpose  of  this  generic  practice  is  to  ensure  that  the  people  have 
the  necessary  skills  and  expertise  to  perform  or  support  the  process. 

Appropriate  training  is  provided  to  the  people  who  will  be  performing  the 
work.  Overview  training  is  provided  to  orient  people  who  interact  with 
those  performing  the  work. 

Examples  of  methods  for  providing  training  include  self-study;  self- 
directed  training;  self-paced,  programmed  instruction;  formalized  on- 
the-job  training;  mentoring;  and  formal  and  classroom  training. 

Training  supports  the  successful  performance  of  the  process  by 
establishing  a  common  understanding  of  the  process  and  by  imparting 
the  skills  and  knowledge  needed  to  perform  the  process. 

Experience  may  be  substituted  for  training  and  means,  for  example, 
having  participated  in  a  project  with  responsibility  for  managing  some  of 
the  acquisition  processes,  [acq] 
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Examples  of  training  topics  include  the  following:  [acq] 

•  Development  of  a  solicitation  package 

•  Negotiation  skills 

•  Risk  identification  and  management 

•  Supplier  agreement  development 

•  Acquisition  management 

•  Acquisition  requirements  development 

Refer  to  the  Organizational  Training  process  area  for  more  information 
on  training  the  people  performing  or  supporting  the  process. 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  under 
appropriate  levels  of  control. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
integrity  of  the  designated  work  products  of  the  process  (or  their 
descriptions)  throughout  their  useful  life. 

The  designated  work  products  are  specifically  identified  in  the  plan  for 
performing  the  process,  along  with  a  specification  of  the  appropriate 
level  of  control. 

Different  levels  of  control  are  appropriate  for  different  work  products  and 
for  different  points  in  time.  For  some  work  products,  it  may  be  sufficient 
to  maintain  version  control  (i.e. ,  the  version  of  the  work  product  in  use 
at  a  given  time,  past  or  present,  is  known  and  changes  are  incorporated 
in  a  controlled  manner).  Version  control  is  usually  under  the  sole  control 
of  the  work  product  owner  (which  may  be  an  individual,  a  group,  or  a 
team). 

Sometimes,  it  may  be  critical  that  work  products  be  placed  under  formal 
or  “baseline”  configuration  management.  This  type  of  control  includes 
defining  and  establishing  baselines  at  predetermined  points.  These 
baselines  are  formally  reviewed  and  agreed  on,  and  serve  as  the  basis 
for  further  development  of  the  designated  work  products. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  on  placing  work  products  under  configuration  management. 

Additional  levels  of  control  between  version  control  and  formal 
configuration  management  are  possible.  An  identified  work  product  may 
be  under  various  levels  of  control  at  different  points  in  time. 

The  acquirer  is  responsible  for  establishing  and  maintaining  baselines 
and  ensures  designated  acquirer  work  products  and  supplier 
deliverables  are  placed  under  appropriate  levels  of  control,  [acq] 


50 


Generic  Goals  and  Practices 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Examples  of  acquirer  work  products  and  supplier  deliverables  placed  under  control 
include  the  following:  [acqj 

•  Project  plans 

•  Solicitation  packages 

•  Measures 

•  Product  documentation 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  as  planned. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
expected  involvement  of  stakeholders  during  the  execution  of  the 
process. 

Involve  relevant  stakeholders  as  described  in  an  appropriate  plan  for 
stakeholder  involvement.  Involve  them  appropriately  in  activities  such 
as  the  following: 

•  Planning 

•  Decisions 

•  Commitments 

•  Communications 

•  Coordination 

•  Reviews 

•  Appraisals 

•  Requirements  definitions 

•  Resolution  of  problems/issues 

Refer  to  the  Project  Planning  process  area  for  information  on  the  project 
planning  for  stakeholder  involvement. 

The  objective  of  planning  the  stakeholder  involvement  is  to  ensure  that 
interactions  necessary  to  the  process  are  accomplished,  while  not 
allowing  excessive  numbers  of  affected  groups  and  individuals  to 
impede  process  execution. 

Relevant  stakeholders  include  the  suppliers  who  develop  the  product 
and  any  suppliers  who  may  be  affected  by  the  product,  [acq] 
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Examples  of  activities  for  supplier  involvement  as  stakeholders  include  the  following: 

[ACQ] 

•  Corrective  action  meetings 

•  Technical  reviews  and  interchanges 

•  Project  status  meetings 

•  Management  reviews 


Subpractices 

1 .  Identify  stakeholders  relevant  to  this  process  and  decide  what  type 
of  involvement  should  be  practiced. 

Relevant  stakeholders  are  identified  among  the  suppliers  of  inputs  to,  the  users  of 
outputs  from,  and  the  performers  of  the  activities  within  the  process.  Once  the 
relevant  stakeholders  are  identified,  the  appropriate  level  of  their  involvement  in 
process  activities  is  planned. 

2.  Share  these  identifications  with  project  planners  or  other  planners 
as  appropriate. 

3.  Involve  relevant  stakeholders  as  planned. 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  against  the  plan  for  performing 
the  process  and  take  appropriate  corrective  action. 


The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day 
monitoring  and  controlling  of  the  process.  Appropriate  visibility  into  the 
process  is  maintained  so  that  appropriate  corrective  action  can  be  taken 
when  necessary.  Monitoring  and  controlling  the  process  involves 
measuring  appropriate  attributes  of  the  process  or  work  products 
produced  by  the  process. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  measurement. 

The  project  collects  and  analyzes  measures  from  the  acquirer  and  from 
the  supplier  in  order  to  effectively  monitor  and  control  the  project,  [acq] 

Subpractices 

1 .  Measure  actual  performance  against  the  plan  for  performing  the 
process. 

The  measures  are  of  the  process,  its  work  products,  and  its  services. 
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2.  Review  accomplishments  and  results  of  the  process  against  the 
plan  for  performing  the  process. 

3.  Review  activities,  status,  and  results  of  the  process  with  the 
immediate  level  of  management  responsible  for  the  process  and 
identify  issues.  The  reviews  are  intended  to  provide  the  immediate 
level  of  management  with  appropriate  visibility  into  the  process. 

The  reviews  can  be  both  periodic  and  event  driven. 

4.  Identify  and  evaluate  the  effects  of  significant  deviations  from  the 
plan  for  performing  the  process. 

5.  Identify  problems  in  the  plan  for  performing  the  process  and  in  the 
execution  of  the  process. 

6.  Take  corrective  action  when  requirements  and  objectives  are  not 
being  satisfied,  when  issues  are  identified,  or  when  progress  differs 
significantly  from  the  plan  for  performing  the  process. 

There  are  inherent  risks  that  should  be  considered  before  any  corrective  action  is 
taken. 

Corrective  action  may  include  the  following: 

•  Taking  remedial  action  to  repair  defective  work  products  or  services 

•  Changing  the  plan  for  performing  the  process 

•  Adjusting  resources,  including  people,  tools,  and  other  resources 

•  Negotiating  changes  to  the  established  commitments 

•  Securing  change  to  the  requirements  and  objectives  that  have  to  be  satisfied 

•  Terminating  the  effort 

7.  Track  corrective  action  to  closure. 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  against  its 
process  description,  standards,  and  procedures,  and  address 
noncompliance. 


The  purpose  of  this  generic  practice  is  to  provide  credible  assurance 
that  the  process  is  implemented  as  planned  and  adheres  to  its  process 
description,  standards,  and  procedures.  This  purpose  is  accomplished, 
in  part,  by  evaluating  selected  work  products  of  the  process.  (See  the 
definition  of  objectively  evaluate  in  the  glossary.) 

Refer  to  the  Process  and  Product  Quality  Assurance  process  area  for 
more  information  about  objectively  evaluating  adherence. 
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GG  3 


People  not  directly  responsible  for  managing  or  performing  the  activities 
of  the  process  typically  evaluate  adherence.  In  many  cases,  adherence 
is  evaluated  by  people  within  the  organization,  but  external  to  the 
process  or  project,  or  by  people  external  to  the  organization.  As  a 
result,  credible  assurance  of  adherence  can  be  provided  even  during 
times  when  the  process  is  under  stress  (e.g.,  when  the  effort  is  behind 
schedule  or  over  budget). 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  with 
higher  level  management  and  resolve  issues. 


The  purpose  of  this  generic  practice  is  to  provide  higher  level 
management  with  the  appropriate  visibility  into  the  process. 

Higher  level  management  includes  those  levels  of  management  in  the 
organization  above  the  immediate  level  of  management  responsible  for 
the  process.  In  particular,  higher  level  management  includes  senior 
management.  These  reviews  are  for  managers  who  provide  the  policy 
and  overall  guidance  for  the  process,  not  for  those  who  perform  the 
direct  day-to-day  monitoring  and  controlling  of  the  process. 

Different  managers  have  different  needs  for  information  about  the 
process.  These  reviews  help  ensure  that  informed  decisions  on  the 
planning  and  performing  of  the  process  can  be  made.  Therefore,  these 
reviews  are  expected  to  be  both  periodic  and  event  driven. 

Proposed  changes  to  commitments  to  be  made  external  to  the 
organization,  for  example,  changes  to  supplier  agreements,  are  typically 
reviewed  with  higher  level  management  to  ensure  that  all  commitments 
can  be  accomplished,  [acq] 


Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a 
description  of  the  process  that  is  tailored  from  the  organization’s  set  of 
standard  processes  to  address  the  needs  of  a  specific  instantiation.  The 
organization  should  have  standard  processes  that  cover  the  process 
area,  as  well  as  have  guidelines  for  tailoring  these  standard  processes 
to  meet  the  needs  of  a  project  or  organizational  function.  With  a  defined 
process,  variability  in  how  the  processes  are  performed  across  the 
organization  is  reduced  and  process  assets,  data,  and  learning  can  be 
effectively  shared. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  set  of  standard  processes  and 
tailoring  guidelines. 

The  descriptions  of  the  defined  processes  provide  the  basis  for 
planning,  performing,  and  managing  the  activities,  work  products,  and 
services  associated  with  the  process. 

Subpractices 

1 .  Select  from  the  organization’s  set  of  standard  processes  those 
processes  that  cover  the  process  area  and  best  meet  the  needs  of 
the  project  or  organizational  function. 

2.  Establish  the  defined  process  by  tailoring  the  selected  processes 
according  to  the  organization’s  tailoring  guidelines. 

3.  Ensure  that  the  organization’s  process  objectives  are  appropriately 
addressed  in  the  defined  process. 

4.  Document  the  defined  process  and  the  records  of  the  tailoring. 

5.  Revise  the  description  of  the  defined  process  as  necessary. 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and 
performing  the  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process 
assets. 


The  purpose  of  this  generic  practice  is  to  collect  information  and 
artifacts  derived  from  planning  and  performing  the  process.  This  generic 
practice  is  performed  so  that  the  information  and  artifacts  can  be 
included  in  the  organizational  process  assets  and  made  available  to 
those  who  are  (or  who  will  be)  planning  and  performing  the  same  or 
similar  processes.  The  information  and  artifacts  are  stored  in  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library. 


Examples  of  relevant  information  include  the  effort  expended  for  the  various  activities, 
defects  injected  or  removed  in  a  particular  activity,  and  lessons  learned. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository  and 
process  asset  library  and  for  more  information  about  the  work  products, 
measures,  and  improvement  information  that  are  incorporated  into 
these  organizational  process  assets. 
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Subpractices 

1 .  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

The  process  and  product  measures  are  primarily  those  that  are  defined  in  the 
common  set  of  measures  for  the  organization’s  set  of  standard  processes. 

2.  Submit  documentation  for  inclusion  in  the  organization’s  process 
asset  library. 

3.  Document  lessons  learned  from  the  process  for  inclusion  in  the 
organization’s  process  asset  library. 

4.  Propose  improvements  to  the  organizational  process  assets. 


GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  process 
that  address  quality  and  process  performance  based  on 
customer  needs  and  business  objectives. 


The  purpose  of  this  generic  practice  is  to  determine  and  obtain 
agreement  from  relevant  stakeholders  about  specific  quantitative 
objectives  for  the  process.  These  quantitative  objectives  can  be 
expressed  in  terms  of  product  quality,  service  quality,  and  process 
performance. 

Refer  to  the  Quantitative  Project  Management  process  area  for 
information  on  how  quantitative  objectives  are  set  for  subprocesses  of 
the  project’s  defined  process. 

The  quantitative  objectives  may  be  specific  to  the  process  or  they  may 
be  defined  for  a  broader  scope  (e.g.,  for  a  set  of  processes).  In  the 
latter  case,  these  quantitative  objectives  may  be  allocated  to  some  of 
the  included  processes. 

These  quantitative  objectives  are  criteria  used  to  judge  whether  the 
products,  services,  and  process  performance  will  satisfy  the  customers, 
end  users,  organization  management,  and  process  implementers. 
These  quantitative  objectives  go  beyond  the  traditional  end-product 
objectives.  They  also  cover  intermediate  objectives  that  are  used  to 
manage  the  achievement  of  the  objectives  over  time.  They  reflect,  in 
part,  the  demonstrated  performance  of  the  organization’s  set  of 
standard  processes.  These  quantitative  objectives  should  be  set  to 
values  that  are  likely  to  be  achieved  when  the  processes  involved  are 
stable  and  within  their  natural  bounds. 
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Subpractices 

1 .  Establish  the  quantitative  objectives  that  pertain  to  the  process. 

2.  Allocate  the  quantitative  objectives  to  the  process  or  its 
subprocesses. 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives. 

The  purpose  of  this  generic  practice  is  to  stabilize  the  performance  of 
one  or  more  subprocesses  of  the  defined  process  that  are  critical 
contributors  to  the  overall  performance  using  appropriate  statistical  and 
other  quantitative  techniques.  Stabilizing  selected  subprocesses 
supports  predicting  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives. 

Refer  to  the  Quantitative  Project  Management  process  area  for 
information  on  selecting  subprocesses  for  statistical  management, 
monitoring  performance  of  subprocesses,  and  other  aspects  of 
stabilizing  subprocess  performance. 

A  stable  subprocess  shows  no  significant  indication  of  special  causes  of 
process  variation.  Stable  subprocesses  are  predictable  within  the  limits 
established  by  the  natural  bounds  of  the  subprocess.  Variations  in  the 
stable  subprocess  are  due  to  a  constant  system  of  chance  causes,  and 
the  magnitude  of  the  variations  can  be  small  or  large. 

Predicting  the  ability  of  the  process  to  achieve  the  established 
quantitative  objectives  requires  a  quantitative  understanding  of  the 
contributions  of  the  subprocesses  that  are  critical  to  achieving  these 
objectives  and  establishing  and  managing  against  interim  quantitative 
objectives  over  time. 

Selected  process  and  product  measures  are  incorporated  into  the 
organization’s  measurement  repository  to  support  process  performance 
analysis  and  future  fact-based  decision  making. 

Subpractices 

1 .  Statistically  manage  the  performance  of  one  or  more  subprocesses 
that  are  critical  contributors  to  the  overall  performance  of  the 
process. 

2.  Predict  the  ability  of  the  process  to  achieve  its  established 
quantitative  objectives  considering  the  performance  of  the 
statistically  managed  subprocesses. 

3.  Incorporate  selected  process  performance  measurements  into  the 
organization’s  process  performance  baselines. 
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GG  5 


Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  process  in  fulfilling  the 
relevant  business  objectives  of  the  organization. 


The  purpose  of  this  generic  practice  is  to  select  and  systematically 
deploy  process  and  technology  improvements  that  contribute  to 
meeting  established  quality  and  process-performance  objectives. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  information  about  selecting  and  deploying  incremental  and 
innovative  improvements  that  measurably  improve  the  organization’s 
processes  and  technologies. 

Optimizing  processes  that  are  agile  and  innovative  depends  on  the 
participation  of  an  empowered  workforce  aligned  with  the  business 
values  and  objectives  of  the  organization.  The  organization’s  ability  to 
rapidly  respond  to  changes  and  opportunities  is  enhanced  by  finding 
ways  to  accelerate  and  share  learning.  Improvement  of  the  processes  is 
inherently  part  of  everybody’s  role,  resulting  in  a  cycle  of  continual 
improvement. 

Subpractices 

1.  Establish  and  maintain  quantitative  process-improvement 
objectives  that  support  the  organization’s  business  objectives. 

The  quantitative  process-improvement  objectives  may  be  specific  to  the  individual 
process  or  they  may  be  defined  for  a  broader  scope  (i.e.,  for  a  set  of  processes), 
with  the  individual  processes  contributing  to  achieving  these  objectives. 

Objectives  that  are  specific  to  the  individual  process  are  typically  allocated  from 
quantitative  objectives  established  for  a  broader  scope. 

These  process-improvement  objectives  are  primarily  derived  from  the 
organization’s  business  objectives  and  from  a  detailed  understanding  of  process 
capability.  These  objectives  are  the  criteria  used  to  judge  whether  the  process 
performance  is  quantitatively  improving  the  organization’s  ability  to  meet  its 
business  objectives.  These  process-improvement  objectives  are  often  set  to 
values  beyond  the  current  process  performance,  and  both  incremental  and 
innovative  technological  improvements  may  be  needed  to  achieve  these 
objectives.  These  objectives  may  also  be  revised  frequently  to  continue  to  drive 
the  improvement  of  the  process  (i.e.,  when  an  objective  is  achieved,  it  may  be  set 
to  a  new  value  that  is  again  beyond  the  new  process  performance). 

These  process-improvement  objectives  may  be  the  same  as,  or  a  refinement  of, 
the  objectives  established  in  the  Establish  Quantitative  Objectives  for  the  Process 
generic  practice,  as  long  as  they  can  serve  as  both  drivers  and  criteria  for 
successful  process  improvement. 
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2.  Identify  process  improvements  that  would  result  in  measurable 
improvements  to  process  performance. 

Process  improvements  include  both  incremental  changes  and  innovative 
technological  improvements.  The  innovative  technological  improvements  are 
typically  pursued  as  efforts  that  are  separately  planned,  performed,  and  managed. 
Piloting  is  often  performed.  These  efforts  often  address  specific  areas  of  the 
processes  that  are  determined  by  analyzing  process  performance  and  identifying 
specific  opportunities  for  significant  measurable  improvement. 

3.  Define  strategies  and  manage  deployment  of  selected  process 
improvements  based  on  the  quantified  expected  benefits,  the 
estimated  costs  and  impacts,  and  the  measured  change  to  process 
performance. 

The  costs  and  benefits  of  these  improvements  are  estimated  quantitatively,  and 
the  actual  costs  and  benefits  are  measured.  Benefits  are  primarily  considered 
relative  to  the  organization’s  quantitative  process-improvement  objectives. 
Improvements  are  made  to  both  the  organization’s  set  of  standard  processes  and 
the  defined  processes. 

Managing  deployment  of  the  process  improvements  includes  piloting  of  changes 
and  implementing  adjustments  where  appropriate,  addressing  potential  and  real 
barriers  to  deployment,  minimizing  disruption  to  ongoing  efforts,  and  managing 
risks. 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other 
problems  in  the  process. 


The  purpose  of  this  generic  practice  is  to  analyze  defects  and  other 
problems  that  were  encountered  in  a  quantitatively  managed  process, 
to  correct  the  root  causes  of  these  types  of  defects  and  problems,  and 
to  prevent  these  defects  and  problems  from  occurring  in  the  future. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  on  identifying  and  correcting  root  causes  of  selected 
defects.  Even  though  the  Causal  Analysis  and  Resolution  process  area 
has  a  project  context,  it  can  be  applied  to  processes  in  other  contexts 
as  well. 

Root  cause  analysis  can  beneficially  be  applied  to  processes  that  are 
not  quantitatively  managed.  However,  the  focus  of  this  generic  practice 
is  to  act  on  a  quantitatively  managed  process,  though  the  final  root 
causes  may  be  found  outside  of  that  process. 
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Applying  Generic  Practices 


This  section  helps  you  to  develop  a  better  understanding  of  the  generic 
practices  and  provides  information  for  interpreting  and  applying  the 
generic  practices  in  your  organization. 

Generic  practices  are  components  that  are  common  to  all  process 
areas.  Think  of  generic  practices  as  reminders.  They  serve  the  purpose 
of  reminding  you  to  do  things  right,  and  are  expected  model 
components. 

For  example,  when  you  are  achieving  the  specific  goals  of  the  Project 
Planning  process  area,  you  are  establishing  and  maintaining  a  plan  that 
defines  project  activities.  One  of  the  generic  practices  that  applies  to  the 
Project  Planning  process  area  is  “Establish  and  maintain  the  plan  for 
performing  the  project  planning  process”  (GP  2.2).  When  applied  to  this 
process  area,  this  generic  practice  reminds  you  to  plan  the  activities 
involved  in  creating  the  plan  for  the  project. 

When  you  are  satisfying  the  specific  goals  of  the  Organizational 
Training  process  area,  you  are  developing  the  skills  and  knowledge  of 
people  in  your  project  and  organization  so  that  they  can  perform  their 
roles  effectively  and  efficiently.  When  applying  the  same  generic 
practice  (GP  2.2)  to  the  Organizational  Training  process  area,  this 
generic  practice  reminds  you  to  plan  the  activities  involved  in 
developing  the  skills  and  knowledge  of  people  in  the  organization. 


Process  Areas  That  Support  Generic  Practices 


While  generic  goals  and  generic  practices  are  the  model  components 
that  directly  address  the  institutionalization  of  a  process  across  the 
organization,  many  process  areas  likewise  address  institutionalization 
by  supporting  the  implementation  of  the  generic  practices.  Knowing 
these  relationships  will  help  you  effectively  implement  the  generic 
practices. 

Such  process  areas  contain  one  or  more  specific  practices  that  when 
implemented 

•  may  also  fully  implement  a  generic  practice 

•  generate  a  work  product  that  is  used  in  the  implementation  of  a 
generic  practice 
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An  example  is  the  Configuration  Management  process  area  and  GP 
2.6,  “Place  designated  work  products  of  the  process  under  appropriate 
levels  of  control.”  To  implement  the  generic  practice  for  one  or  more 
process  areas,  you  might  choose  to  implement  the  Configuration 
Management  process  area,  all  or  in  part,  to  implement  the  generic 
practice. 

Another  example  is  the  Organizational  Process  Definition  process  area 
and  GP  3.1,  “Establish  and  maintain  the  description  of  a  defined 
process.”  To  implement  this  generic  practice  for  one  or  more  process 
areas,  you  should  first  implement  the  Organizational  Process  Definition 
process  area,  all  or  in  part,  to  establish  the  organizational  process 
assets  that  are  needed  to  implement  the  generic  practice. 

Table  5.2  describes  (1 )  the  process  areas  that  support  the 
implementation  of  generic  practices,  and  (2)  the  recursive  relationships 
between  generic  practices  and  their  closely  related  process  areas.  Both 
types  of  relationships  are  important  to  remember  during  process 
improvement  to  take  advantage  of  the  natural  synergies  that  exist 
between  the  generic  practices  and  their  related  process  areas. 

Table  5.2:  Generic  Practice  and  Process  Area  Relationships 


Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP2.2 

Plan  the  Process 

Project  Planning:  The  project  planning 
process  can  implement  GP  2.2  in  full  for 
all  project-related  process  areas  (except 
for  Project  Planning  itself). 

GP  2.2  applied  to  the  project  planning 
process  can  be  characterized  as  “plan 
the  plan”  and  covers  planning  the 
project  planning  activities. 

GP  2.3 

Provide 

Resources 

GP  2.4 

Assign 

Responsibility 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.4, 

“Plan  for  necessary  resources  to 
perform  the  project,”  supports  the 
implementation  of  GP  2.3  and  GP  2.4 
for  all  project-related  process  areas 
(except  perhaps  initially  for  Project 
Planning  itself)  by  identifying  needed 
processes,  roles,  and  responsibilities  to 
ensure  the  proper  staffing,  facilities, 
equipment,  and  other  assets  needed  by 
the  project  are  secured. 

14  When  the  relationship  between  a  generic  practice  and  a  process  area  is  less  direct,  the  risk  of  confusion  is 
reduced;  therefore,  we  do  not  describe  all  recursive  relationships  in  the  table  (e.g.,  for  generic  practices  2.3, 
2.4,  and  2.10). 
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Generic  Practice 


GP2.5 
Train  People 


GP  2.6 

Manage 

Configurations 


GP  2.7 
Identify  and 
Involve  Relevant 
Stakeholders 


Roles  of  Process  Areas  in  How  the  Generic  Practice  Recursively 

Implementation  of  the  Generic  Practice  Applies  to  its  Related  Process  Area(s) 14 


Organizational  Training:  The 

organizational  training  process  supports 
the  implementation  of  GP  2.5  as  applied 
to  all  process  areas  by  making  the 
training  that  addresses  strategic  or 
organization-wide  training  needs 
available  to  those  who  will  perform  or 
support  the  process. 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.5, 
“Plan  for  knowledge  and  skills  needed  to 
perform  the  project,”  together  with  the 
organizational  training  process,  supports 
the  implementation  of  GP  2.5  in  full  for 
all  project-related  process  areas. 

Configuration  Management:  The 

configuration  management  process  can 
implement  GP  2.6  in  full  for  all  project- 
related  process  areas  as  well  as  some 
of  the  organizational  process  areas. 


Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.6, 
“Plan  the  involvement  of  identified 
stakeholders,”  can  implement  the 
stakeholder  identification  part  (first  two 
subpractices)  of  GP  2.7  in  full  for  all 
project-related  process  areas. 

Project  Monitoring  and  Control:  The 

part  of  the  project  monitoring  and  control 
process  that  implements  Project 
Monitoring  and  Control  SP  1.5,  “Monitor 
Stakeholder  Involvement,”  can  aid  in 
implementing  the  third  subpractice  of 
GP  2.7  for  all  project-related  process 
areas. 

Integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  2.1, 
“Manage  Stakeholder  Involvement,”  can 
aid  in  implementing  the  third  subpractice 
of  GP  2.7  for  all  project-related  process 
areas. 


GP  2.5  applied  to  the  organizational 
training  process  area  covers  training  for 
performing  the  organizational  training 
activities,  which  addresses  the  skills 
required  to  manage,  create,  and 
accomplish  the  training. 


GP  2.6  applied  to  the  configuration 
management  process  covers  change 
and  version  control  for  the  work 
products  produced  by  configuration 
management  activities. 


GP  2.7  applied  to  the  project  planning 
process  covers  the  involvement  of 
relevant  stakeholders  in  project  planning 
activities. 

GP  2.7  applied  to  the  project  monitoring 
and  control  process  covers  the 
involvement  of  relevant  stakeholders  in 
project  monitoring  and  control  activities. 

GP  2.7  applied  to  the  integrated  project 
management  process  covers  the 
involvement  of  relevant  stakeholders  in 
integrated  project  management 
activities. 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP2.8 

Monitor  and 
Control  the 
Process 

Project  Monitoring  and  Control:  The 

project  monitoring  and  control  process 
can  implement  GP  2.8  in  full  for  all 
project-related  process  areas. 

GP  2.8  applied  to  the  project  monitoring 
and  control  process  covers  the 
monitoring  and  controlling  of  the 
project’s  monitor  and  control  activities. 

Measurement  and  Analysis:  For  all 

processes,  not  just  project-related 
processes,  the  Measurement  and 

Analysis  process  area  provides  general 
guidance  about  measuring,  analyzing, 
and  recording  information  that  can  be 
used  in  establishing  measures  for 
monitoring  actual  performance  of  the 
process. 

GP  2.9 

Objectively 

Evaluate 

Adherence 

Process  and  Product  Quality 
Assurance:  The  process  and  product 
quality  assurance  process  can 
implement  GP  2.9  in  full  for  all  process 
areas  (except  perhaps  for  Process  and 
Product  Quality  Assurance  itself). 

GP  2.9  applied  to  the  process  and 
product  quality  assurance  process 
covers  the  objective  evaluation  of  quality 
assurance  activities. 

GP  2.10 

Review  Status 
with  Higher  Level 
Management 

Project  Monitoring  and  Control:  The 

part  of  the  project  monitoring  and  control 
process  that  implements  Project 
Monitoring  and  Control  SP  1.6,  “Conduct 
Progress  Reviews,”  and  SP  1.7, 

“Conduct  Milestone  Reviews,”  supports 
the  implementation  of  GP  2. 1 0  for  all 
project-related  process  areas,  perhaps 
in  full,  depending  on  higher  level 
management  involvement  in  these 
reviews. 

GP  3.1 

Establish  a 
Defined  Process 

Integrated  Project  Management:  The 

part  of  the  integrated  project- 
management  process  that  implements 
Integrated  Project  Management  SP  1.1, 
“Establish  and  maintain  the  project’s 
defined  process,”  can  implement  GP  3.1 
in  full  for  all  project-related  process 
areas. 

GP  3.1  applied  to  the  integrated  project 
management  process  covers 
establishing  defined  processes  for 
integrated  project  management 
activities. 

Organizational  Process  Definition: 

For  all  processes,  not  just  project- 
related  processes,  the  organizational 
process  definition  process  establishes 
the  organizational  process  assets 
needed  to  implement  GP  3.1. 
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Generic  Practice 


GP  3.2 
Collect 
Improvement 
Information 


Roles  of  Process  Areas  in  How  the  Generic  Practice  Recursively 

Implementation  of  the  Generic  Practice  Applies  to  its  Related  Process  Area(s) 14 


Integrated  Project  Management:  The 

part  of  the  integrated  project- 
management  process  that  implements 
Integrated  Project  Management  SP  1.6, 
“Contribute  work  products,  measures, 
and  documented  experiences  to  the 
organizational  process  assets,”  can 
implement  GP  3.2  in  full  for  all  project- 
related  process  areas. 

Organizational  Process  Focus:  The 

part  of  the  organizational  process  focus 
process  that  implements  Organizational 
Process  Focus  SP  2.4,  “Incorporate 
process-related  work  products, 
measures,  and  improvement  information 
derived  from  planning  and  performing 
the  process  into  the  organizational 
process  assets,”  can  implement  GP  3.2 
in  part  or  full  for  all  process  areas. 

Organizational  Process  Definition: 

For  all  processes,  the  organizational 
process  definition  process  establishes 
the  organizational  process  assets 
needed  to  implement  GP  3.2. 


GP  3.2  applied  to  the  integrated  project 
management  process  covers  collecting 
improvement  information  derived  from 
planning  and  performing  the  integrated 
project  management  activities. 
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Generic  Practice 


GP  4.1 
Establish 
Quantitative 
Objectives  for 
the  Process 


GP  4.2 
Stabilize 
Subprocess 
Performance 


Roles  of  Process  Areas  in  How  the  Generic  Practice  Recursively 

Implementation  of  the  Generic  Practice  Applies  to  its  Related  Process  Area(s) 14 


Quantitative  Project  Management: 

The  part  of  the  quantitative  project- 
management  process  that  implements 
Quantitative  Project  Management  SP 
1.1,  “Establish  and  maintain  the  project’s 
quality  and  process-performance 
objectives,”  supports  the  implementation 
of  GP  4.1  for  all  project-related  process 
areas  by  providing  objectives  from  which 
the  objectives  for  each  particular 
process  can  be  derived.  If  these 
objectives  become  established  as  part 
of  implementing  subpractices  5  and  8  of 
Quantitative  Project  Management  SP 
1.1,  then  the  quantitative  project- 
management  process  implements  GP 
4.1  in  full. 

Organizational  Process 
PerformanceiThe  part  of  the 
organizational  process  performance 
process  that  implements  Organizational 
Process  Performance  SP  1.3,  “Establish 
and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the 
organization,”  supports  the 
implementation  of  GP  4.1  for  all  process 
areas. 

Quantitative  Project  Management: 

The  part  of  the  quantitative  project- 
management  process  that  implements 
Quantitative  Project  Management  SG  2, 
“Statistically  Manage  Subprocess 
Performance,”  can  implement  GP  4.2  in 
full  for  all  project-related  process  areas 
to  which  a  statistically  managed 
subprocess  can  be  mapped. 

Organizational  Process  Performance: 

For  all  processes,  not  just  project- 
related  processes,  the  organizational 
process  performance  process 
establishes  organizational  process 
assets  that  may  be  needed  to  implement 
GP  4.2. 


GP  4.1  applied  to  the  quantitative 
project  management  process  covers 
establishing  quantitative  objectives  for 
quantitative  project  management 
activities. 

GP  4.1  applied  to  the  organizational 
process  performance  process  covers 
establishing  quantitative  objectives  for 
organizational  process  performance 
activities. 


GP  4.2  applied  to  the  quantitative 
project  management  process  covers  the 
stabilization  of  selected  subprocesses 
within  quantitative  project  management 
activities. 


Generic  Goals  and  Practices 
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Generic  Practice 

Roles  of  Process  Areas  in 

Implementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursively 
Applies  to  its  Related  Process  Area(s) 14 

GP  5.1 

Ensure 

Continuous 

Process 

Improvement 

Organizational  Innovation  and 
Deployment:  The  organizational 
innovation  and  deployment  process  can 
implement  GP  5.1  in  full  for  all  process 
areas  providing  that  quality  and  process- 
performance  objectives  for  the 
organization  have  been  defined.  (The 
latter  would  be  the  case,  say,  if  the 
Organizational  Process  Performance 
process  area  has  been  implemented.) 

GP  5.1  applied  to  the  organizational 
innovation  and  deployment  process 
covers  ensuring  continuous  process 
improvement  of  organizational 
innovation  and  deployment  activities. 

GP  5.2 

Correct  Root 
Causes  of 
Problems 

Causal  Analysis  and  Resolution:  The 

causal  analysis  and  resolution  process 
can  implement  GP  5.2  in  full  for  all 
project-related  process  areas. 

GP  5.2  applied  to  the  causal  analysis 
and  resolution  process  covers 
identifying  root  causes  of  defects  and 
other  problems  in  the  causal  analysis 
and  resolution  activities. 

Given  the  dependencies  that  generic  practices  have  on  these  process 
areas,  and  given  the  more  “holistic”  view  that  many  of  these  process 
areas  provide,  these  process  areas  are  often  implemented  early,  in 

whole  or  in  part,  before  or  concurrent  with  implementing  the  associated 
generic  practices. 

There  are  also  a  few  situations  where  the  result  of  applying  a  generic 
practice  to  a  particular  process  area  would  seem  to  make  a  whole 
process  area  redundant,  but,  in  fact,  it  does  not.  It  may  be  natural  to 
think  that  applying  GP  3.1 ,  Establish  a  Defined  Process,  to  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas  gives  the 
same  effect  as  the  first  specific  goal  of  Integrated  Project  Management, 
“The  project  is  conducted  using  a  defined  process  that  is  tailored  from 
the  organization’s  set  of  standard  processes.” 

Although  it  is  true  that  there  is  some  overlap,  the  application  of  the 
generic  practice  to  these  two  process  areas  provides  defined  processes 
covering  project  planning  and  project  monitoring  and  control  activities. 
These  defined  processes  do  not  necessarily  cover  support  activities 
(such  as  configuration  management),  other  project-management 
processes  (such  as  project  planning),  or  the  engineering  processes.  In 
contrast,  the  project’s  defined  process,  provided  by  the  Integrated 
Project  Management  process  area,  covers  all  appropriate  project 
management,  engineering,  and  support  processes,  [acq] 
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ACQUISITION  MANAGEMENT 


An  Acquisition  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Acquisition  Management  (AM)  is  to  ensure  that  the 
supplier’s  performance  meets  contractual  requirements  and  that  the 
acquirer  performs  according  to  the  terms  of  the  supplier  agreement. 


Introductory  Notes 


The  Acquisition  Management  process  area  involves  the  following: 

•  Maintaining  ongoing  communications  and  mutual  understanding 
with  the  supplier 

•  Resolving  issues  and  disputes 

•  Revising  and  closing  the  supplier  agreements 

•  Accepting  delivery  of  acquired  products 

•  Transitioning  acquired  products  to  the  project 

•  Managing  the  payment  to  the  supplier 

The  legal  nature  of  the  acquirer-supplier  relationship  makes  it 
imperative  that  the  project  management  team  is  acutely  aware  of  the 
legal  implications  of  actions  taken  when  managing  any  acquisition  of 
products  or  services. 

The  supplier  agreement  is  the  basis  for  managing  the  relationship  with 
the  supplier,  including  resolving  issues  and  disputes.  It  defines  the 
mechanisms  to  allow  the  acquirer  to  oversee  the  supplier’s  activities 
and  evolving  products,  and  to  verify  compliance  with  supplier 
agreement  requirements.  It  also  provides  the  vehicle  for  mutual 
understanding  between  the  acquirer  and  the  supplier. 

Deviations  from  the  project  plan  may  cause  changes  to  the  supplier 
agreement  and  significant  changes  to  the  supplier  agreement  may 
require  the  project  plan  to  be  modified.  When  the  supplier’s 
performance,  processes,  or  products  fail  to  satisfy  established  criteria 
as  outlined  in  the  supplier  agreement,  the  acquirer  may  decide  to  apply 
legal  remedies. 
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Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  projects  and  taking  corrective  action. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  defining  steps  for  escalation  of  issues. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  identifying  and  analyzing  alternatives. 

Refer  to  the  Acquisition  Validation  process  area  for  information  about 
validating  products. 

Refer  to  the  Acquisition  Verification  process  area  for  information  about 
verifying  supplier  deliverables. 

Specific  Goal  and  Practice  Summary 

SG  1  Manage  Supplier  Agreements 

SP  1 . 1  Manage  Supplier  Agreement  Communications 
SP  1 .2  Resolve  Supplier  Agreement  Issues  and  Disputes 
SP  1 .3  Revise  Supplier  Agreements 
SP1.4  Close  Supplier  Agreements 
SG  2  Satisfy  Supplier  Agreements 

SP  2.1  Accept  the  Acquired  Product 

SP  2.2  Transition  Products 

SP  2.3  Manage  Payments  to  Suppliers 


Specific  Practices  by  Goal 


SG  1  Manage  Supplier  Agreements 

Manage  changes  and  revise  the  supplier  agreement  if  necessary  and 
resolve  supplier  agreement  issues  or  disputes. 


SP  1.1  Manage  Supplier  Agreement  Communications 

Manage  supplier  agreement  communications  between  the 
acquirer  and  the  supplier  about  the  relationship,  performance, 
results,  and  impact  to  the  business 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  stakeholder  involvement. 
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This  specific  practice  covers  communications  internally  and  externally 
as  well  as  the  use  of  such  information  by  acquirer  and  supplier  to 
support  marketing  and  public  relations.  The  acquirer  manages  the 
relationship  with  the  supplier  to  maintain  effective  communication  on 
key  issues,  for  example,  change  in  the  acquirer’s  business,  new 
supplier  products  and  technologies,  and  changes  in  the  organizational 
structure. 

Typical  Acquirer  Work  Products 

1.  Marketing  and  communications  material 

2.  Correspondence  between  acquirer  and  supplier 


SP  1.2  Resolve  Supplier  Agreement  Issues  and  Disputes 

Resolve  issues  and  disputes  associated  with  the  supplier 
agreement  and  determine  corrective  actions  necessary  to 
address  the  issues  and  disputes. 


This  specific  practice  represents  the  escalation  of  unresolved  issues 
between  the  acquirer  and  supplier  through  multiple  phases  of  escalation 
for  an  issue  between  acquirer  and  supplier  before  possible  litigation. 

The  acquirer  collects  supplier  agreement  related  issues  or  disputes  and 
tracks  these  issues  and  disputes  until  resolution.  Issues  related  to  the 
supplier’s  performance  may  be  escalated  from  progress  or  milestone 
reviews,  for  example.  If  the  supplier  does  not  comply  appropriately  with 
the  acquirer's  initiation  of  corrective  action,  the  acquirer  escalates  and 
handles  the  issue  as  a  supplier  agreement  dispute. 

The  supplier  may  also  escalate  issues  related  to  the  agreement, 
especially  those  related  to  the  acquirer  meeting  specified  commitments. 
Each  issue  is  tracked  from  identification  or  receipt  to  resolution 
according  to  the  escalation  process  or  procedure  defined  in  the  supplier 
agreement.  The  resolution  may  require  a  change  to  the  supplier 
agreement.  Relevant  stakeholders,  for  example,  senior  managers, 
contract  manager,  governance  bodies,  legal  consultants,  project 
manager,  suppliers,  may  be  requested  to  participate  in  resolution  of  an 
issue  to  prevent  the  issue  becoming  the  subject  of  an  agreement 
dispute. 

Typical  Acquirer  Work  Products 

1 .  List  of  escalated  issues  and  disputed  issues 

2.  Corrective  action  plan 

3.  Corrective  action  results 

4.  Resolution  of  Agreement  issues  and  disputes  (e.g.,  proposed 
supplier  agreement  language) 
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5.  Correspondence  with  supplier 

Typical  Supplier  Deliverables 

1 .  List  of  escalated  issues  and  disputed  issues 

2.  Corrective  action  plans  for  supplier  issues 

3.  Corrective  action  results  for  supplier  issues 

4.  Correspondence  with  acquirer 

Subpractices 

1 .  Gather  escalated  issues  associated  with  the  supplier  agreement  for 
analysis. 

2.  Determine  and  document  the  appropriate  actions  need  to  address 
the  escalated  issues. 

Collect  documentation  and  backup  material  relevant  to  the  issue  and  interpret 
supplier  agreement  to  compile  advantages  and  disadvantages  of  various  positions 
for  resolution 

3.  Review  escalated  issues  per  the  process  or  procedure  in  the 
supplier  agreement  and  resolve  if  possible. 

4.  Classify  issues  not  resolved  through  escalation  as  disputed  issues. 

5.  Build  negotiations  team  and  strategy  to  resolve  the  disputed 
issues. 

6.  Conduct  dispute  resolution  as  required  by  the  supplier  agreement. 

Communicate  proposed  dispute  resolution  to  the  supplier  or  analyze  supplier’s 
proposed  dispute  resolution. 

7.  Monitor  escalated  issues  and  disputes  for  completion. 

8.  Analyze  results  of  issues  and  dispute  resolution  to  determine  its 
effectiveness. 

9.  Document  resolution  of  escalated  issues  and  disputes  and 
communicate  as  needed. 


SP  1.3  Revise  Supplier  Agreements 

Revise  the  supplier  agreement  to  reflect  changes  in  conditions 
where  appropriate. 
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After  award  of  the  supplier  agreement,  the  acquirer  may  find 
requirements  that  are  no  longer  optimal  or  applicable  based  on  the 
supplier’s  progress  or  environment  changes.  Examples  include 
availability  of  new  technology,  overly  burdensome  documentation,  and 
reporting  requirements.  Changes  to  supplier  agreements  may  also 
occur  when  the  supplier’s  processes  or  products  fail  to  meet  agreed  to 
criteria  and  service  levels. 

All  changes  are  formally  documented  and  approved  by  both  the 
acquirer  and  the  supplier  before  being  implemented  by  this  specific 
practice.  Approved  change  requests  can  include  modifications  to  the 
terms  and  conditions  of  the  supplier  agreement,  including  the  statement 
of  work,  pricing,  and  description  of  products,  services,  or  results  to  be 
acquired. 

Refer  to  the  Configuration  Management  process  area  for  information 
about  tracking  and  controlling  changes. 

Typical  Acquirer  Work  Products 

1.  Revised  Supplier  Agreement 

SP  1.4  Close  Supplier  Agreements 

Close  the  supplier  agreement  after  verifying  completion  of  all 
supplier  requirements. 


This  practice  addresses  each  supplier  agreement  applicable  to  the 
project  or  a  project  phase.  Depending  on  the  acquisition  life  cycle,  the 
term  of  the  supplier  agreement  may  only  be  applicable  to  a  given  phase 
of  the  project.  In  these  cases,  this  specific  practice  closes  the  supplier 
agreement(s)  applicable  to  that  phase  of  the  project.  When  a  supplier 
agreement  is  applicable  to  an  entire  project,  this  specific  practice 
typically  closes  the  project.  Unresolved  issues  or  disputes  may  be 
subject  to  litigation  after  supplier  agreement.  The  terms  and  conditions 
of  the  supplier  agreement  can  prescribe  specific  procedures  for  supplier 
agreement  closure. 

Early  termination  of  a  supplier  agreement  is  a  special  case  of  supplier 
agreement  closure,  and  can  result  from  a  mutual  agreement  of  the 
acquirer  and  supplier  or  from  the  default  of  one  of  the  parties.  The  rights 
and  responsibilities  of  the  acquirer  and  supplier  in  the  event  of  an  early 
termination  are  contained  in  the  termination  clause  of  the  supplier 
agreement. 

Typical  Acquirer  Work  Products 
1.  Supplier  agreement  file 
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Subpractices 

1 .  Verify  with  stakeholders  that  all  supplier  activities  and  supplier 
deliverables  specified  in  the  agreement  have  been  received  and 
accepted. 

The  acquirer  verifies,  for  instance,  that  any  warranty  has  been  completed 
according  to  the  supplier  agreement  and  that  all  regulatory  requirements  have 
been  met.  This  may  also  include  a  final  supplier  evaluation  related  to  the 
agreement. 

Refer  to  the  Acquisition  Verification  process  area  for  information 
about  verifying  supplier  deliverables. 

2.  Ensure  that  all  records  related  to  the  supplier  agreement  are 
stored,  managed,  and  controlled  for  future  use. 

The  acquirer  documents  the  performance  of  the  supplier  as  a  basis  for  future 
relationships  with  the  supplier.  Supplier  performance  evaluation  by  the  acquirer  is 
primarily  carried  out  to  confirm  the  competency  or  lack  of  competency  of  the 
supplier,  relative  to  performing  similar  work  on  the  project  or  other  projects. 

Refer  to  the  Project  Monitoring  and  Control  Process  area  for 
information  about  performing  progress  and  milestone  reviews. 

3.  Communicate  to  appropriate  stakeholders  that  the  supplier 
agreement  has  been  closed. 

The  acquirer,  usually  through  its  authorized  supplier  agreement  or  contract 
administrator,  provides  the  supplier  with  formal  written  notice  that  the  supplier 
agreement  has  been  completed. 


SG  2  Satisfy  Supplier  Agreements 

Establish  a  productive  and  cooperative  environment  to  meet  the  goals  of 
the  project. 


SP  2.1  Manage  Payment  to  Supplier 

Receive,  review,  approve,  and  remit  invoices  provided  by  the 
supplier. 


This  practice  handles  invoices  for  any  type  of  charge,  for  example,  one¬ 
time,  monthly,  deliverable-based,  pass-through,  expenses.  It  handles 
invoice  errors  or  disputes,  changes  to  invoices,  billing  errors,  and 
withholding  disputed  charges  consistent  with  the  terms  and  conditions 
of  the  supplier  agreement.  The  acquirer  must  adhere  to  regulatory 
requirements,  for  example,  tax  deductions,  in  managing  payments  to 
the  supplier.  The  acquirer  must  also  ensure  that  appropriate  financial 
controls  are  in  place. 
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The  intent  of  this  practice  is  to  ensure  that  payment  terms  defined  within 
the  supplier  agreement  are  met  and  that  supplier  compensation  is 
linked  to  supplier  progress,  as  defined  in  the  supplier  agreement.  When 
accepting  supplier  deliverables,  final  payment  should  not  be  made  to 
the  supplier  until  it  has  been  certified  that  all  the  supplier  deliverables 
meet  the  contractual  requirements  and  that  all  acceptance  criteria  have 
been  satisfied.  To  the  degree  that  nonperformance  is  encountered, 
exercise  the  contract  provisions  for  withholding  or  reducing  payments  to 
the  supplier. 

Typical  Acquirer  Work  Products 

1 .  Invoices  Approved  for  Payment 

Typical  Supplier  Deliverables 

1.  Invoices 

Subpractices 

1.  Review  invoice  and  related  supporting  material. 

:  Examples  of  areas  of  review  for  invoices  and  related  support  material  include  the 
|  following: 

:  •  Volumes  for  any  variable  charges 
i  •  Pass  through  expenses 
I  •  Regulatory  commitments  related  to  payments 
•  Purchases  made  by  supplier  on  behalf  of  acquirer 

2.  Resolve  errors  /  manage  disputes  with  supplier  as  required. 

3.  Process  invoice  for  payment. 


SP  2.2  Accept  Acquired  Product 

Ensure  that  the  supplier  agreement  is  satisfied  before 
accepting  the  acquired  product. 


The  acquirer  ensures  that  all  acceptance  criteria  have  been  satisfied 
and  that  all  discrepancies  have  been  corrected.  Requirements  for 
formal  deliverable  acceptance,  and  how  to  address  non-conforming 
deliverables,  are  usually  defined  in  the  supplier  agreement.  The 
acquirer  should  be  prepared  to  exercise  all  remedies  in  case  the 
supplier  fails  to  perform. 

The  acquirer,  usually  through  its  authorized  supplier  agreement  or 
contract  administrator,  provides  the  supplier  with  formal  written  notice 
that  the  supplier  deliverables  have  been  accepted  or  rejected. 
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With  this  specific  practice,  an  authorized  representative  of  the  acquirer 
assumes  ownership  of  existing  identified  supplier  products  or 
deliverables  tendered,  or  approves  specific  services  rendered,  as  partial 
or  complete  performance  of  the  supplier  agreement  on  the  part  of  the 
supplier. 

Typical  Acquirer  Work  Products 

1 .  Stakeholder  approval  reports 

2.  Discrepancy  reports 

3.  Product  acceptance  review  report  with  approval  signatures 

Typical  Supplier  Deliverables 

1 .  Work  products  as  defined  in  the  supplier  agreement 
Subpractices 

1 .  Review  the  validation  results,  reports,  logs,  and  issues  for  the 
acquired  product. 

Refer  to  the  Acquisition  Validation  process  area  for  more 
information  about  validating  products. 

2.  Confirm  that  all  customer  requirements  and  stakeholder  intentions 
associated  with  the  acquired  product  are  satisfied. 

3.  Review  the  verification  results,  reports,  logs,  and  issues  for  the 
acquired  product. 

Refer  to  the  Acquisition  Verification  process  area  for  more 
information  about  verifying  products. 

4.  Confirm  that  all  contractual  requirements  associated  with  the 
acquired  product  are  satisfied. 

This  may  include  confirming  that  the  appropriate  license,  warranty,  ownership, 
usage,  and  support  or  maintenance  agreements  are  in  place  and  that  all 
supporting  materials  are  received. 

5.  Confirm  that  all  discrepancies  have  been  corrected  and  that  all 
acceptance  criteria  have  been  satisfied. 

6.  Communicate  the  product’s  readiness  for  transition  to  operations 
and  support  and  also  the  product’s  status  to  stakeholders. 


SP  2.3  Transition  Product 

Transition  the  acquired  product  from  the  supplier  to  the 
acquirer. 
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Typically,  the  supplier  integrates  and  packages  the  products  and 
prepares  for  the  transition  to  operations  and  support,  including  support 
for  business  user  acceptance,  and  the  acquirer  oversees  the  supplier 
activities.  These  expectations  and  the  acceptance  criteria  for  transition 
to  operations  and  support  are  included  in  the  solicitation  package  and 
then  supplier  agreement. 

Typical  Acquirer  Work  Products 

1.  Transition  readiness  report 

2.  Transfer  of  ownership 

3.  Transition  analysis  report 

Typical  Supplier  Deliverables 

1.  Transition  plans 

2.  Training  reports 

3.  Pilot  results 

Subpractices 

1 .  Ensure  the  completion  of  installation  of  the  product  in  the 
production  environment. 

2.  Conduct  pilot  or  initial  implementation,  as  appropriate. 

The  acquirer,  following  appropriate  reviews  of  the  transition  activities,  makes  the 
product  available  for  use  according  to  the  plans  for  pilot  and  transition.  During  this 
pilot  or  initial  period  of  production,  the  acquirer  validates  that  the  product  is 
capable  and  ready  for  full  operational  use.  During  this  defined  transition  or 
warranty  period,  for  example,  30  days  or  90  days,  the  acquirer  oversees  activities 
to  make  sure  the  product  is  operating  as  planned  and  identifies  any  corrective 
actions  required.  Although  the  product  is  in  the  operational  environment,  full 
responsibility  for  operations  and  support  is  not  transitioned  until  this  pilot  period  is 
complete  and  any  corrective  actions  identified  have  been  successfully  completed. 
During  this  defined  transition  period,  the  acquirer  ensures  support  of  the  product, 
for  example,  the  supplier  may  be  given  responsibility  to  maintain  support  during 
the  transition. 

Ensure  the  viability  of  either  dual  operations  or  the  capability  to  back-out  the 
product  before  transitioning  to  the  production  environment 

3.  Transfer  responsibility  for  operations  and  support. 
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Responsibility  for  operations  and  support  of  the  product  is  transferred  by  the 
acquirer  to  the  operations  and  support  organizations,  which  may  be  suppliers, 
only  after  the  operations  and  support  organization  demonstrates  its  capability  and 
capacity  to  support  the  product  and  accept  the  responsibilities  to  perform  their 
assigned  operations  and  support  processes.  The  acquirer  ensures  the  operations 
and  support  organizations  understand  post-transition  service  requirements  from 
the  supplier. 

The  acquirer  maintains  oversight  responsibilities  until  the  transition  activities  are 
complete  and  the  transfer  of  responsibility  for  operations  and  support  of  the 
product  has  been  accepted.  This  includes  oversight  of  any  supplier  activities, 
based  upon  the  supplier  agreement,  for  the  execution  of  the  transition  of  the 
product  to  operations  and  support. 

4.  Analyze  the  results  of  transition  activities. 

After  the  transition  is  complete  and  the  responsibility  transferred  to  the  operational 
and  support  organizations  (e.g.,  at  the  end  of  the  warranty  period  for  a  software 
product),  the  acquirer  reviews  and  analyzes  the  results  of  the  transition  activities 
and  determines  whether  any  corrective  actions  must  be  completed  before  close. 

The  following  typical  reports  and  logs  are  used  in  the  analysis  by  the  acquirer: 

•  Results  of  transition  activities  including  defects/quality  related  measures  collected 
during  pilot  and  warranty  period 

•  Problem  tracking  reports,  detailing  resolution  time,  incident  response,  escalation, 
and  root  cause  analysis 

•  Change  management  reports 

•  Operation  logs  to  determine  that  sufficient  information  is  stored  to  support 
reconstruction 

•  Configuration  management  records 

•  Violation  of  security  activity  reports 

•  Actual  operations  costs  compared  to  estimates 

•  Actual  support  costs  compared  to  estimates 

5.  Analyze  the  actual  operations  and  support  cost  against  the 
estimated  costs. 

Follow  warranty  terms  and  conditions  to  resolve  problems  during  period  following 
transition. 

6.  Ensure  that  storing,  distributing,  and  using  the  acquired  products 
are  in  compliance  with  the  terms  and  conditions  specified  in  the 
supplier  agreement  or  license. 
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ACQUISITION  REQUIREMENTS  DEVELOPMENT 

An  Acquisition  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Acquisition  Requirements  Development  (ARD)  is  to 
produce  and  analyze  customer  and  contractual  requirements. 


Introductory  Notes 


Requirements  are  the  basis  for  the  selection  and  for  the  design  or 
configuration  of  the  acquired  product.  The  development  of  requirements 
includes  the  following  activities: 

•  Elicitation,  analysis,  validation,  and  communication  of  customer 
needs,  expectations,  and  constraints  to  obtain  customer 
requirements  that  constitute  an  understanding  of  what  will  satisfy 
stakeholders 

•  Collection  and  coordination  of  stakeholder  needs 

•  Development  of  the  life-cycle  requirements  of  the  product 

•  Establishment  of  the  customer  requirements 

•  Establishment  of  contractual  requirements  consistent  with  customer 
requirements  to  a  level  of  detail  that  is  sufficient  to  be  included  in 
the  solicitation  package  and  supplier  agreement 

The  requirements  included  in  the  solicitation  package  form  the  basis  for 
evaluating  alternate  proposals  by  suppliers  and  for  further  negotiations 
with  the  suppliers  and  communication  with  the  customer.  The 
contractual  requirements  for  the  supplier  are  baselined  in  the  supplier 
agreement. 

Requirements  are  identified  and  refined  throughout  the  project  life 
cycle.  Design  decisions,  subsequent  corrective  actions,  and  feedback 
during  each  phase  of  the  project’s  life  cycle  are  analyzed  for  impact  on 
contractual  requirements. 

Requirements  analyses  aid  in  understanding,  defining,  and  selecting 
the  requirements  at  all  levels  from  competing  alternatives.  Analyses 
occur  recursively  at  successively  more  detailed  levels  until  sufficient 
detail  is  available  to  produce  contractual  requirements  and  to  further 
refine  these,  if  necessary,  while  the  supplier  builds  or  configures  the 
product. 
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Involvement  of  relevant  stakeholders  in  both  requirements  development 
and  analyses  gives  them  visibility  into  the  evolution  of  requirements. 
Participation  continually  assures  the  stakeholders  that  the  requirements 
are  being  properly  defined. 

The  Acquisition  Requirements  Development  process  area  includes 
three  specific  goals.  The  Develop  Customer  Requirements  specific  goal 
addresses  eliciting  and  defining  a  set  of  customer  requirements.  The 
Develop  Contractual  Requirements  specific  goal  addresses  defining  a 
set  of  contractual  requirements  that  are  based  on  customer 
requirements  and  included  in  the  solicitation  package  and  supplier 
agreement.  The  specific  practices  of  the  Analyze  and  Validate 
Requirements  specific  goal  support  the  development  of  the 
requirements  in  both  the  Develop  Customer  Requirements  specific  goal 
and  the  Develop  Contractual  Requirements  specific  goal.  The  specific 
practices  associated  with  this  specific  goal  cover  analyzing  and 
validating  the  requirements  with  respect  to  the  acquirer’s  intended 
environment. 

The  processes  associated  with  the  Acquisition  Requirements 
Development  process  area  and  those  associated  with  the  Acquisition 
Technical  Solution  process  area  may  interact  recursively  with  one 
another,  for  instance,  to  iteratively  refine  requirements. 


Related  Process  Areas 


Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements  and  changes,  obtaining 
agreement  with  the  requirements  provider,  obtaining  commitments  with 
those  implementing  the  requirements,  and  maintaining  traceabiiity. 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  how  the  outputs  of  the  requirements  development 
processes  are  used  for  defining  technical  constraints 

Refer  to  the  Acquisition  Verification  process  area  for  more  information 
about  verifying  that  the  resulting  product  meets  the  contractual 
requirements. 

Refer  to  the  Acquisition  Validation  process  area  for  more  information 
about  how  the  requirements  will  be  validated  against  the  stakeholder 
intentions. 
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Specific  Goal  and  Practice  Summary 

SG  1  Develop  Customer  Requirements 
SP1.1  Elicit  Needs 

SP  1 .2  Develop  the  Customer  Requirements 

SG  2  Develop  Contractual  Requirements 

SP  2.1  Establish  Contractual  Requirements 

SP  2.2  Allocate  Contractual  Requirements 

SG  3  Analyze  and  Validate  Requirements 

SP  3.1  Establish  Operational  Concepts  and  Scenarios 

SP  3.2  Analyze  Requirements 

SP  3.3  Analyze  Requirements  to  Achieve  Balance 

SP  3.4  Validate  Requirements  with  Comprehensive  Methods 


Specific  Practices  by  Goal 


SG  1  Develop  Customer  Requirements 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected 
and  translated  into  customer  requirements. 

The  intentions  of  stakeholders  (e.g.,  customers,  end  users,  suppliers, 
supplier  agreement  management  personnel,  manufacturers,  and 
logistics  support  personnel)  are  the  basis  for  determining  requirements. 
The  stakeholder  needs,  expectations,  constraints,  interfaces, 
operational  concepts,  and  product  concepts  are  analyzed,  harmonized, 
refined,  and  elaborated  for  translation  into  a  set  of  customer 
requirements. 

Frequently,  the  stakeholders’  intentions  are  poorly  identified  or 
conflicting.  Since  the  stakeholders’  intensions  must  be  clearly  identified 
and  understood  throughout  the  project  life  cycle,  an  iterative  process  is 
used  throughout  the  life  of  the  project  to  accomplish  this  objective.  To 
facilitate  the  required  interaction,  relevant  stakeholders  are  frequently 
involved  throughout  the  project  life  cycle  to  communicate  their  needs, 
expectations,  constraints  and  help  resolve  conflicts.  Environmental, 
legal,  and  other  constraints  should  be  considered  when  creating  and 
evolving  the  set  of  requirements  for  acquiring  products  or  services. 

SP  1.1  Elicit  Needs 

Elicit  stakeholder  needs,  expectations,  constraints,  and 
interfaces  for  all  phases  of  the  product  life  cycle. 


Eliciting  goes  beyond  collecting  requirements  by  proactively  identifying 
additional  requirements  not  explicitly  provided  by  the  stakeholders. 
Relevant  stakeholders  representing  all  phases  of  the  product’s  life  cycle 
in  the  acquirer’s  intended  environment  should  include  business  as  well 
as  technical  functions.  In  this  way,  needs  for  all  product-related  life- 
cycle  processes  are  considered  concurrently  with  the  concepts  for  the 
acquired  products. 
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Analyses  of  business  processes  is  a  common  source  of  stakeholder 
needs,  expectations,  constraints,  and  interfaces.  Additional  needs 
typically  address  the  various  project  life-cycle  activities  and  their  impact 
on  the  product. 


Examples  of  techniques  to  elicit  needs  for  current  and  potential  customers  and  other 
stakeholders  include  the  following: 

•  Questionnaires,  interviews,  and  operational  scenarios  obtained  from  end  users 

•  Operational  walkthroughs  and  end-user  task  analysis 

•  Prototypes  and  models 

•  Observation  of  existing  products,  environments,  and  workflow  patterns 

•  Technology  demonstrations 

•  Interim  project  reviews 

•  Brainstorming 

•  Quality  Function  Deployment 

•  Market  surveys 

•  Extraction  from  sources  such  as  business  process  documents,  standards,  or 
specifications 

•  Use  cases 

•  Business  case  analyses 

•  Reverse  engineering  (for  legacy  products) 


Examples  of  sources  of  requirements  that  might  not  be  identified  by  the  customer 
include  the  following: 

•  Government  regulations 

•  Policies  and  standards 

•  Technology 

•  Legacy  products  or  product  components  (for  reuse) 


Typical  Acquirer  Work  Products 
1.  Stakeholder  intentions 

Subpractices 

1 .  Engage  relevant  stakeholders  using  methods  for  eliciting  needs, 
expectations,  constraints,  and  external  interfaces. 


SP  1.2  Develop  the  Customer  Requirements 

Transform  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  customer  requirements. 
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The  customer  typically  describes  requirements  as  capabilities 
expressed  in  broad  operational  terms  concerned  with  achieving  a 
desired  effect  underspecified  standards  and  regulations.  The  various 
inputs  from  the  customer  and  other  stakeholders  must  be  aligned  to  the 
organization’s  strategy,  missing  information  must  be  obtained,  and 
conflicts  must  be  resolved  as  the  customer  requirements  are 
documented  (e.g.,  customer  requirements  that  exist  as  an  output  of 
another  project’s  activities  such  as  a  previous  project  that  delivered  the 
initial  capability). 


Examples  of  considerations  for  expressing  customer  requirements  include  the  following: 

•  Key  characteristics  (attributes)  of  the  desired  capability  with  appropriate 
parameters  and  measures 

•  Obstacles  to  overcome  to  achieve  the  capability 

•  Competitive  gap  between  existing  and  desired  capability 

•  Supportability  of  desired  capability 

•  Level  of  detail  of  customer  requirements  so  as  not  to  prejudice  decisions  in  favor  of 
a  particular  means  of  implementation,  but  specific  enough  to  evaluate  alternative 
approaches  to  implement  the  capability 


Typical  Acquirer  Work  Products 

1 .  Prioritized  customer  requirements 

2.  Customer  constraints  on  the  conduct  of  verification 

3.  Customer  constraints  on  the  conduct  of  validation 

Subpractices 

1.  Translate  the  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  documented  customer  requirements. 

2.  Prioritize  customer  requirements 

3.  Define  constraints  for  verification  and  validation. 


SG  2  Develop  Contractual  Requirements 

Customer  requirements  are  refined  and  elaborated  to  develop  contractual 
requirements. 

Customer  requirements  are  analyzed  in  conjunction  with  the 
development  of  the  operational  concept  to  derive  more  detailed  and 
precise  sets  of  requirements  called  contractual  requirements  to  be 
included  in  the  solicitation  package  for  potential  suppliers  and 
eventually  in  the  supplier  agreement.  The  level  of  detail  of  contractual 
requirements  is  determined  based  on  the  acquisition  strategy  and 
project  characteristics. 
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Contractual  requirements  arise  from  constraints,  consideration  of  issues 
implied  but  not  explicitly  stated  in  the  customer  requirements  baseline, 
and  factors  introduced  by  the  design  constraints  and  the  supplier’s 
capabilities.  The  requirements  are  reexamined  throughout  the  project 
life  cycle. 

The  requirements  are  allocated  to  supplier  deliverables.  The  traceability 
of  requirements  to  supplier  deliverables  is  documented. 

Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements  specific 
practice  of  the  Requirements  Management  process  area  for  more 
information  about  maintaining  bidirectional  traceability. 


SP  2.1  Establish  Contractual  Requirements 

Establish  and  maintain  contractual  requirements,  which  are 
based  on  the  stakeholder  requirements. 


The  customer  requirements  may  be  expressed  in  the  customer’s  terms 
and  may  be  non-technical  descriptions.  The  contractual  requirements 
are  the  expression  of  these  requirements  in  technical  terms  that  can  be 
used  for  design  decisions.  An  example  of  this  translation  is  found  in  the 
first  House  of  Quality  Functional  Deployment,  which  maps  customer 
desires  into  technical  parameters.  For  instance,  “solid  sounding  door” 
might  be  mapped  to  size,  weight,  fit,  dampening,  and  resonant 
frequencies. 

In  addition  to  technical  requirements  (e.g.,  requirements  specifying 
interface  with  other  products  or  applications,  functional  requirements 
and  their  validation,  and  verification  requirements  such  as  product 
acceptance  criteria),  contractual  requirements  also  cover  non-technical 
stakeholder  needs,  expectations,  and  constraints. 
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Examples  of  considerations  for  non-technical  requirements  include  the  following: 

•  Frequency  and  format  of  supplier  reviews 

•  Standard  measures  and  service  levels  for  the  technical  solution 

•  Supplier  reports  and  other  communications 

•  Availability  of  support  to  meet  levels  of  business  process  or  product  performance. 

•  Warranty  of  products  provided  by  a  supplier 

•  Logistics  support  that  sustains  both  short  and  long-term  readiness 

•  Minimal  total  life  cycle  cost  to  own  and  operate  (i.e.,  minimal  total  ownership  cost). 

•  Maintenance  concepts  that  optimize  readiness  while  drawing  upon  both  acquirer 
and  supplier  sources 

•  Data  management  and  configuration  management  that  facilitates  cost-effective 
product  support  throughout  the  product’s  use  by  the  acquirer. 


The  modification  of  requirements  due  to  approved  requirement  changes 
is  covered  by  the  “maintain”  function  of  this  specific  practice;  whereas, 
the  administration  of  requirement  changes  is  covered  by  the 
Requirements  Management  process  area. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  changes  to  requirements. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  developing  solicitation  packages  and 
supplier  agreements. 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  design  constraints. 

Typical  Acquirer  Work  Products 
1.  Contractual  requirements 

Subpractices 

1 .  Develop  functional  requirements  necessary  for  development  of 
alternate  solutions  and  the  product  by  the  supplier. 

Functional  requirements  or  definition  of  functionality  can  include  actions, 
sequence,  inputs,  outputs,  or  other  information  that  communicates  the  manner  in 
which  the  product  will  be  used.  Functionality  required  may  be  prioritized  as 
Critical/Must-Have,  Good-to-Flave,  and  Optional  requirements. 

2.  Develop  interface  requirements  of  the  acquired  product  to  other 
products  in  the  intended  environment. 
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Requirements  for  interfaces  are  defined  in  terms  of  origination,  destination, 
stimulus,  data  characteristics  for  software,  and  electrical  and  mechanical 
characteristics  for  hardware. 

3.  Develop  requirements  for  verification  and  validation  of  the  product 
developed  by  the  supplier. 

Requirements  for  verification  and  validation  typically  include  types  and  coverage 
of  testing  and  review  to  be  carried  out  in  the  supplier’s  and  acquirer’s 
environment.  Testing  requirements  may  include  mirroring  the  production 
environment  by  the  supplier,  type  of  test  data  to  be  used,  and  simulated  testing  for 
interfaces  with  other  products. 

Review  requirements  may  include  the  form  of  review  to  be  used  (e.g.,  walk¬ 
through,  prototype  review)  and  the  required  participants  for  reviews. 

4.  Develop  requirements  and  constraints  in  technical  terms  necessary 
for  development  of  alternate  solutions  and  the  product  developed 
by  the  supplier. 

Refer  to  the  Acquisition  Technical  Solution  process  area  for 
defining  design  constraints. 

Design  constraints  express  the  qualities  and  performance  points  that  are  critical  to 
the  success  of  the  product  in  the  acquirer’s  operational  environment.  They 
account  for  customer  requirements  in  the  context  of  multiple  interoperable 
products.  The  project  needs  to  identify  any  dependencies  on  planned  or  existing 
products.  This  must  take  project  or  program  constraints  into  account  (e.g., 
affordability  and  schedule  constraints). 

Acquirers  may  accelerate  the  development  of  technical  requirements  and  design 
constraints  by  reusing  shared  or  common  constraints  or  requirements  and  their 
associated  test  cases  from  previous  acquisitions  or  by  leveraging  the  supplier’s 
previous  product  developments. 

5.  Establish  and  maintain  relationships  between  requirements  for 
consideration  during  change  management  and  requirements 
allocation. 

Relationships  between  requirements  can  aid  in  evaluating  the  impact  of  changes. 
Expected  requirements  volatility  is  also  a  key  factor  anticipating  scope  changes 
and  supporting  the  acquirer’s  selection  of  the  appropriate  acquisition  type. 


SP  2.2  Allocate  Contractual  Requirements 

Allocate  the  requirements  for  each  supplier  deliverable. 


The  requirements  for  each  supplier  deliverables  are  documented.  In 
some  cases,  this  includes  allocation  of  technical  requirements  to  third- 
party  products  that  must  be  used  by  the  supplier  (e.g.,  commercial  off 
the  shelf  products). 
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Typical  Acquirer  Work  Products 

1 .  Requirement  allocation  sheets 


SG  3 


Subpractices 

1 .  Allocate  requirements  to  supplier  deliverables. 

2.  Allocate  design  constraints  to  supplier  deliverables. 

3.  Document  relationships  among  allocated  requirements  and  design 
constraints. 

Relationships  include  dependencies  in  which  a  change  in  one  requirement  may 
affect  other  requirements. 

4.  Allocate  requirements  to  suppliers. 

In  situations  where  multiple  suppliers  are  involved  in  developing  the  technical 
solution,  different  products  or  product  components  may  be  allocated  to  different 
suppliers. 


Analyze  and  Validate  Requirements 

The  requirements  are  analyzed  and  validated. 

Analyses  are  performed  to  determine  what  impact  the  intended 
operational  environment  will  have  on  the  ability  to  satisfy  the 
stakeholders’  needs,  expectations,  constraints,  and  interfaces. 
Considerations,  such  as  feasibility,  mission  needs,  cost  constraints, 
potential  market  size,  and  acquisition  strategy,  must  all  be  taken  into 
account,  depending  on  the  product  context. 

The  objectives  of  the  analyses  are  to  determine  candidate  requirements 
for  product  concepts  that  will  satisfy  stakeholder  needs,  expectations, 
and  constraints;  and  then  to  translate  these  concepts  into  requirements. 
In  parallel  with  this  activity,  the  parameters  that  will  be  used  to  evaluate 
the  effectiveness  of  the  product  are  determined  based  on  customer 
input  and  the  preliminary  product  concept. 

Requirements  are  validated  to  increase  the  probability  that  the  resulting 
product  will  perform  as  intended  in  the  acquirer’s  environment. 


SP  3.1  Establish  Operational  Concepts  and  Scenarios 

Establish  and  maintain  operational  concepts  and  associated 
scenarios. 
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Operational  concepts  or  concepts  of  operations  give  an  overall 
description  of  the  way  in  which  an  acquired  product  is  intended  to  be 
used  or  operated,  deployed,  supported  (including  maintenance  and 
sustainment),  and  disposed.  For  that,  the  acquirer  takes  design 
constraints  explicitly  into  account.  For  example,  the  operational  concept 
for  a  satellite-based  communications  product  is  quite  different  from  one 
based  on  landlines. 

In  contrast,  an  operational  scenario  is  a  sequence  of  events  that  might 
occur  in  the  use  of  the  acquired  product  and  that  make  explicit  some 
stakeholder  intentions.  Typically,  operational  scenarios  are  derived  from 
business  process  descriptions  and  operational  concepts. 

The  operational  concepts  and  scenarios  are  refined  as  solution 
decisions  are  made  and  more  detailed  requirements  are  developed. 
They  are  evolved  to  facilitate  the  validation  of  the  technical  solutions 
delivered  by  the  supplier. 

Typical  Acquirer  Work  Products 

1.  Operational  concepts 

2.  Operational  scenarios 

3.  Requirements 

Subpractices 

1 .  Develop  operational  concepts  and  scenarios  that  include 
functionality,  performance,  maintenance,  support,  and  disposal  as 
appropriate. 

Identify  and  develop  concepts  and  scenarios,  consistent  with  the  level  of  detail  in 
the  stakeholder  needs,  expectations,  and  constraints,  in  which  the  proposed 
product  is  expected  to  operate. 

2.  Define  the  environment  the  product  will  operate  in,  including 
boundaries  and  constraints. 

3.  Review  operational  concepts  and  scenarios  to  refine  and  discover 
requirements. 

Operational  concept  and  scenario  development  is  an  iterative  process.  The 
reviews  should  be  held  periodically  to  ensure  that  they  agree  with  the 
requirements.  The  review  may  be  in  the  form  of  a  walkthrough. 

4.  Develop  a  detailed  operational  concept,  as  products  and  product 
components  are  developed  by  the  supplier,  that  defines  the 
interaction  of  the  product,  the  end  user,  and  the  environment,  and 
that  satisfies  the  operational,  maintenance,  support,  and  disposal 
needs. 
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SP  3.2  Analyze  Requirements 

Analyze  requirements  to  ensure  that  they  are  necessary  and 
sufficient. 


As  contractual  requirements  are  defined,  their  relationship  to  customer 
requirements  must  be  understood.  In  light  of  the  operational  concept 
and  scenarios,  the  contractual  requirements  are  analyzed  to  determine 
whether  they  are  necessary  and  sufficient  to  meet  the  customer 
requirements.  The  analyzed  requirements  then  provide  the  basis  for 
more  detailed  and  precise  requirements  throughout  the  project  life 
cycle. 

One  of  the  other  actions  is  the  determination  of  which  key  requirements 
will  be  used  to  track  technical  progress.  For  instance,  the  weight  of  a 
product  or  size  of  a  software  product  may  be  monitored  through 
development  based  on  its  risk. 

Typical  Acquirer  Work  Products 

1.  Requirements  defects  reports 

2.  Proposed  requirements  changes  to  resolve  defects 

3.  Key  requirements 

4.  Technical  performance  measures 

Subpractices 

1.  Analyze  stakeholder  needs,  expectations,  constraints,  and  external 
interfaces  to  remove  conflicts  and  to  organize  into  related  subjects. 

2.  Analyze  requirements  to  determine  whether  they  satisfy  the 
objectives  of  higher  level  requirements. 

3.  Analyze  requirements  to  ensure  that  they  are  complete,  feasible, 
realizable,  and  verifiable. 

4.  Identify  key  requirements  that  have  a  strong  influence  on  cost, 
schedule,  functionality,  risk,  or  performance. 

5.  Identify  technical  performance  measures  that  will  be  tracked  during 
the  acquisition  effort. 

The  total  number  of  performance  parameters  should  be  the  minimum  number 
needed  to  characterize  the  major  drivers  of  the  product’s  performance.  The 
number  and  specificity  of  performance  parameters  may  change  over  time.  Early  in 
a  project  or  program  the  requirements  baseline  should  reflect  broadly-defined 
measures  of  technology  effectiveness  or  measures  of  performance  to  describe 
needed  capabilities.  As  a  program  or  project  matures  and  requirements  become 
better  defined  it  allows  for  more  detailed  technical  performance  measures,  if 
necessary.  Data  for  technical  performance  measures  is  provided  by  the  supplier 
as  specified  in  the  supplier  agreement. 
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Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  use  of  measurements. 

6.  Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new 
requirements. 

This  analysis  may  result  in  more  detailed  operational  concepts  and  scenarios  as 
well  as  supporting  the  derivation  of  new  requirements. 


SP  3.3  Analyze  Requirements  to  Achieve  Balance 

Analyze  requirements  to  balance  stakeholder  needs  and 
constraints. 


Stakeholder  needs  and  constraints  can  address  cost,  schedule, 
performance,  functionality,  reusable  components,  maintainability,  or 
risk. 

Typical  Acquirer  Work  Products 

1 .  Assessment  of  risks  related  to  requirements 

Subpractices 

1.  Use  proven  models,  simulations,  and  prototyping  to  analyze  the 
balance  of  stakeholder  needs  and  constraints. 

Results  of  the  analyses  can  be  used  to  reduce  the  cost  of  the  product  and  the  risk 
in  acquiring  and  using  the  product. 

2.  Perform  a  risk  assessment  on  the  requirements  and  design 
constraints. 

Refer  to  the  Risk  Management  process  area  for  information  about 
performing  a  risk  assessment  on  customer  and  contractual 
requirements  and  the  design  constraints. 

3.  Examine  product  life-cycle  concepts  for  impacts  of  requirements  on 
risks. 


SP  3.4  Validate  Requirements  with  Comprehensive  Methods 

Validate  requirements  to  ensure  the  resulting  product  will 
perform  as  intended  in  the  user’s  environment  using  multiple 
techniques  as  appropriate. 
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Requirements  validation  is  performed  early  in  the  acquisition  effort  to 
gain  confidence  that  the  requirements  are  capable  of  guiding  a 
development  that  results  in  successful  final  validation.  This  activity 
should  be  integrated  with  risk  management  activities.  Mature 
organizations  will  typically  perform  requirements  validation  in  a  more 
sophisticated  way  using  multiple  techniques  and  will  broaden  the  basis 
of  the  validation  to  include  other  stakeholder  needs  and  expectations. 
These  organizations  will  typically  perform  analyses,  simulations,  or 
prototypes  to  ensure  that  requirements  will  satisfy  stakeholder  needs 
and  expectations. 


Examples  of  techniques  used  for  requirements  validation  include  the  following: 
:  •  Analysis 

:  •  Simulations 

i  •  Prototyping 

•  Demonstrations 


Typical  Acquirer  Work  Products 

1 .  Records  of  analysis  methods  and  results 

Typical  Supplier  Deliverables 

1.  Requirements  and  validation  methods  (e.g.,  prototypes  and 
simulations) 

Subpractices 

1 .  Analyze  the  requirements  to  determine  the  risk  that  the  resulting 
product  will  not  perform  appropriately  in  its  intended-use 
environment. 

2.  Explore  the  adequacy  and  completeness  of  requirements  by 
developing  product  representations  (e.g.,  prototypes,  simulations, 
models,  scenarios,  and  storyboards)  and  by  obtaining  feedback 
about  them  from  relevant  stakeholders. 

Refer  to  the  Acquisition  Validation  process  area  for  information 
about  preparing  for  and  performing  validation  on  products  and 
product  components. 

3.  Assess  the  product  and  product  components  as  they  are 
developed  by  the  supplier  in  the  context  of  the  validation 
environment  to  identify  issues  and  expose  unstated  needs  and 
customer  requirements. 
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ACQUISITION  TECHNICAL  SOLUTION 

An  Acquisition  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Acquisition  Technical  Solution  (ATS)  is  to  develop 
design  constraints  and  to  verify  the  technical  solution  of  the  supplier. 


Introductory  Notes 


The  acquirer  provides  design  constraints  to  the  supplier.  The  product  or 
service  are  designed  and  implemented  by  the  supplier  consistent  with 
the  acquirer’s  design  constraints.  The  Acquisition  Technical  Solution 
process  area  focuses  on  the  following: 

•  Developing  design  constraints  for  the  supplier’s  technical  solution 
that  potentially  satisfy  an  appropriate  set  of  allocated  requirements. 

•  Verify  detailed  designs  for  the  selected  solutions  (detailed  in  the 
context  of  containing  all  the  information  needed  to  manufacture, 
code,  or  otherwise  implement  the  design  as  a  product  or  service) 

•  Analyze  and  verify  the  development  and  implementation  of  the 
supplier’s  technical  solution  to  ensure  contractual  requirements  are 
met 

Typically,  these  activities  interactively  support  each  other.  Some  level  of 
design,  at  times  fairly  detailed,  may  be  needed  to  select  solutions. 
Prototypes  created  by  the  supplier  may  be  used  as  a  means  of  gaining 
sufficient  knowledge  to  develop  more  comprehensive  design 
constraints. 


Related  Process  Areas 


Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  requirements  allocations,  establishing  an 
operational  concept,  and  interface  requirements  definition. 

Refer  to  the  Acquisition  Verification  process  area  for  more  information 
about  conducting  reviews  and  verifying  that  the  product  and  product 
components  meet  requirements. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation. 
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Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements.  The  specific  practices  in  the 
Requirements  Management  process  area  are  performed  interactively 
with  those  in  the  Acquisition  Technical  Solution  process  area. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  the  organization’s  technology. 

Specific  Goal  and  Practice  Summary 

SG  1  Develop  Technical  Constraints 

SP  1 . 1  Establish  a  Definition  of  Design  Constraints 
SP  1 .2  Verify  Design  with  Comprehensive  Methods 
SG  2  Analyze  and  Verify  Technical  Solution 
SP2.1  Analyze  Technical  Solution 

SP  2.2  Analyze  Interface  Descriptions  for  Completeness 


Specific  Practices  by  Goal 


SG  1  Develop  Technical  Constraints 

Constraints  for  the  technical  solution  are  developed  and  satisfied  by  the 
supplier’s  design. 


SP  1.1  Establish  a  Definition  of  Design  Constraints 

Determine  the  design  constraints  for  a  technical  solution. 


Design  constraints  express  the  qualities  and  performance  points  that 
are  critical  to  the  success  of  the  product  in  the  acquirer’s  operational 
environment.  Design  constraints  may  include  standards  and  design 
rules  governing  development  of  products  and  their  interfaces.  The 
criteria  for  interfaces  are  often  associated  with  safety,  security, 
durability,  and  mission-critical  characteristics. 

To  achieve  high  levels  of  reuse  and  interoperability,  acquirers  typically 
establish  common  design  constraints  for  products  or  product  families 
that  can  be  deployed  in  one  or  more  domain.  Common  design 
constraints  (also  reference  architectures  or  product  line  architecture) 
provide  a  proven  bundling  of  products,  applications  and  configurations. 
They  provide  a  base  for  creating  technical  solutions  that  use  design 
constraints  more  reliably  and  cost  effectively. 
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Example  tasks  for  identifying  common  design  criteria  may  include  the  following: 

•  Establishing  the  structural  relations  of  products  and  rules  regarding  interfaces 
between  products 

•  Identifying  external  interfaces 

•  identifying  common  products  and  common  interfaces 

•  Developing  reference  architectures  or  frameworks 

•  Establishing  design  rules  and  authority  for  making  decisions 

•  Defining  criteria  for  physical  deployment  of  software  to  hardware 

•  Identifying  major  reuse  approaches  and  sources  including  legacy  and  COTS 
products 

Design  criteria  can  be  a  part  of  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  and  maintaining  organizational  process 
assets. 

Typical  Acquirer  Work  Products 

1 .  Design  constraints  including  criteria  for  design  and  product  reuse 

2.  Guidelines  for  choosing  COTS  products 

3.  Alternative  solution  screening  criteria 

4.  Selection  criteria  for  final  selection 

Subpractices 

1 .  Define  interface  criteria  between  the  supplier’s  product  and  the 
acquirer’s  operational  environment. 

2.  Develop  criteria  for  the  reuse  of  products  and  other  existing  assets 
like  design  elements,  code  components,  etc. 

Analyze  implications  for  maintenance  when  using  off-the-shelf  or  non- 
developmental  items  (e.g.,  COTS,  government  off  the  shelf,  and  reuse). 

:  Examples  of  implications  for  maintenance  include  the  following: 

:  •  the  compatibility  with  future  releases  of  COTS  products 
i  •  Configuration  management  of  vendor  changes 
j  •  Defects  in  a  reused  or  off-the-shelf  product  and  their  resolution 
:  •  Unplanned  obsolescence  of  off-the-shelf  products. 

3.  Establish  and  maintain  criteria  against  which  the  supplier’s  design 
and  product  can  be  evaluated. 
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An  acquirer  typically  specifies  in  the  supplier  agreement  how  the  supplier  has  to 
document  the  design. 

Examples  of  attributes,  in  addition  to  expected  performance,  for  which  design 
criteria  can  be  established,  include  the  following: 

•  Modular 

•  Clear 

•  Simple 

•  Maintainable 

•  Verifiable 

•  Portable 

•  Reliable 

•  Accurate 

•  Secure 

•  Scalable 

•  Usable 


4.  Identify  screening  criteria  to  select  a  set  of  alternate  solutions  for 
considerations. 

5.  Develop  the  criteria  for  selecting  the  best  alternative  solution. 

Criteria  should  be  included  that  address  design  issues  for  the  life  of  the  product, 
such  as  provisions  for  more  easily  inserting  new  technologies  or  the  ability  to 
better  exploit  commercial  products.  Examples  include  criteria  related  to  open 
design  or  open  architecture  concepts  for  the  alternatives  being  evaluated. 

6.  Document  the  design  constraints. 


SP  1.2  Verify  Design  with  Comprehensive  Methods 

Verify  design  to  ensure  the  resulting  product  will  perform  as 
intended  in  the  acquirer’s  environment. 


Design  verification  (or  technical  review  or  architectural  evaluation)  is 
performed  throughout  the  project  life  cycle  to  gain  confidence  that  the 
requirements  are  capable  of  guiding  a  development  that  results  in  a 
satisfactory  technical  solution.  This  activity  should  be  integrated  with 
risk  management  activities.  Mature  organizations  will  typically  perform 
design  verification  in  a  more  sophisticated  way  using  multiple 
techniques  and  will  broaden  the  basis  of  the  verification  to  include  other 
stakeholder  needs  and  expectations. 
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Examples  of  techniques  used  for  design  verification  include  the  following: 

•  Analysis 

•  Simulations 

•  Architectural  prototyping 

•  Demonstrations 


Typical  Acquirer  Work  Products 

1 .  Record  of  analysis  methods  and  results 

Typical  Supplier  Deliverables 

1 .  Alternative  solutions 

2.  Product  architecture 

3.  Product-component  designs 

4.  Technical  data  package 

5.  Interface  design  specifications 

6.  Interface  control  documents 

7.  Interface  specification  criteria 

8.  Criteria  for  design  and  product-component  reuse 

9.  Make-or-buy  analyses 

10.  Documented  solutions,  evaluations,  and  rationale 

1 1 .  Updated  Requirements  Traceability  Matrix 

Subpractices 

1 .  Evaluate  each  alternative  solution/set  of  solutions  presented  by 
suppliers  against  the  selection  criteria. 

2.  Based  on  the  evaluation  of  alternatives,  assess  the  adequacy  of 
the  selection  criteria  and  update  the  criteria  as  necessary. 

3.  Select  the  best  set  of  alternative  solutions  that  satisfy  the 
established  criteria. 

4.  Ensure  that  the  selected  design  adheres  to  applicable  design 
standards  and  criteria. 

5.  Ensure  that  the  design  adheres  to  allocated  requirements. 

For  example,  putting  required  COTS  products  into  the  product  architecture  might 
modify  the  requirements  and  the  requirements  allocation. 
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6.  Analyze  the  supplier’s  design  to  determine  the  risk  that  the 
resulting  product  will  not  perform  appropriately  in  its  intended-use 
environment. 

7.  Explore  the  adequacy  and  completeness  of  the  supplier’s  design 
by  reviewing  product  representations  (e.g.,  prototypes,  simulations, 
models,  scenarios,  and  storyboards)  and  by  obtaining  feedback 
about  them  from  relevant  stakeholders. 

Refer  to  the  Acquisition  Verification  process  area  for  information 
about  preparing  for  and  performing  verification  on  supplier 
deliverables. 

8.  Assess  the  design  as  it  matures  in  the  context  of  the  requirements 
to  identify  issues  and  expose  unstated  needs  and  customer 
requirements. 


SG  2  Analyze  and  Verify  Technical  Solution 

Analyze  and  verify  the  development  and  implementation  of  the  technical 
solution  by  supplier. 

The  supplier  implements  the  design  verified  by  acquirer  under  Verify 
Design  with  Comprehensive  Methods  practice.  The  implementation  by 
supplier  includes  development  of  product  components,  integration  of 
the  components,  unit  and  integration  testing  of  the  product  and 
development  of  end-user  documentation. 

The  acquirer  verifies  the  implementation  to  ensure  allocated 
requirements  have  been  met  by  the  implementation  and  the  product  is 
ready  to  be  brought  into  acquirer  environment  for  further  integration  and 
user  acceptance  testing. 


SP  2.1  Verify  Technical  Solution 

Verify  the  technical  solution  implementation  by  supplier  to 
ensure  contractual  requirements  continue  to  be  met. 


The  acquirer  examines  a  product  to  determine  if  it  is  ready  for 
production  and  if  the  supplier  has  accomplished  adequate  production 
planning.  The  verification  also  examines  risk;  it  determines  if  production 
or  production  preparations  incur  unacceptable  risks  that  might  breach 
objectives  of  schedule,  performance,  cost,  or  other  established  criteria. 
The  acquirer  evaluates  the  full,  production-configured  product  to 
determine  if  it  correctly  and  completely  implements  all  contractual 
requirements.  The  acquirer  also  determines  whether  the  traceability  of 
final  contractual  requirements  to  the  final  production-configured  product 
is  maintained. 
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A  successful  verification  of  the  technical  solution  is  predicated  on  the 
acquirer’s  determination  that  the  requirements  are  fully  met  in  the  final 
production  configuration,  and  that  production  capability  forms  a 
satisfactory  basis  for  proceeding  into  pilots  or  full-rate  production. 


Examples  of  success  criteria  for  the  verification  of  the  supplier’s  technical  solution 
include  the  following: 

•  Established  and  documented  product  baseline  that  enables  hardware  fabrication 
and  software  coding  to  proceed  with  proper  configuration  management 

•  Adequate  production  processes  and  measures  are  in  place  for  the  project  to 
succeed 

•  Risks  are  managed  effectively 

•  The  detailed  design  is  producible  within  the  production  budget 


The  acquirer  convenes  verifications  of  the  technical  solution  with 
suppliers  and  subcontractors,  as  applicable.  Verifications  are  conducted 
in  an  iterative  fashion,  concurrently  with  other  technical  reviews,  such 
as  design  reviews. 


Examples  of  considerations  for  follow-on  verifications  of  technical  solutions  include  the 
following: 

•  Changes  during  the  production  stage  of  the  project,  in  either  materials  or 
manufacturing  processes,  occur 

•  Production  start-up  or  re-start  occurs  after  a  significant  shutdown  period 

•  Production  start-up  with  a  new  supplier 

•  Relocation  of  a  manufacturing  site 


Typical  Acquirer  Work  Products 

1 .  Record  of  verification  methods  and  results 

Typical  Supplier  Deliverables 

1.  Product  components 

2.  System  Documentation 

3.  Supplier  unit  and  integration  test  plans 

4.  Unit  and  Integration  test  results 

5.  Updated  Requirements  Traceability  Matrix 

Subpractices 

1 .  Ensure  that  the  implementation  adheres  to  applicable  standards 
and  criteria. 

2.  Ensure  that  the  implementation  adheres  to  allocated  requirements. 
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3.  Verify  that  the  implementation  has  been  sufficiently  tested  by  the 
supplier. 

4.  Verify  that  the  issues  identified  during  testing  have  been  resolved 
appropriately,  with  product  revisions,  if  necessary. 

5.  Ensure  sufficient  end  user  documentation  has  been  developed  and 
is  in  alignment  with  the  tested  implementation. 


SP  2.2  Analyze  Interface  Descriptions  for  Completeness 

Analyze  the  product  interface  descriptions  to  ensure  they  are 
complete  and  in  alignment  with  the  intended  environment. 


Examples  criteria  for  interfaces  that  typically  are  the  focus  of  the  acquirer’s  analyses 
include  the  following: 

•  The  interface  spans  organizational  boundaries. 

•  The  interface  is  mission  critical. 

•  The  interface  is  difficult  or  complex  to  manage. 

•  Capability,  interoperability,  or  efficiency  issues  are  associated  with  the  interface. 

•  The  interface  impacts  multiple  acquisition  project  or  programs. 


Typical  Acquirer  Work  Products 

1 .  Record  of  analysis  methods  and  results 

Typical  Supplier  Deliverables 

1.  Interface  description  documents 

Subpractices 

1 .  Ensure  that  the  interface  description  adheres  to  applicable 
standards,  criteria,  and  required  interface  requirements  between 
the  supplier’s  product  and  acquirer’s  intended  environment. 

2.  Ensure  that  the  interface  description  adheres  to  allocated 
requirements. 

3.  Verify  that  the  interfaces  have  been  sufficiently  tested  by  the 
supplier 

4.  Verify  that  the  issues  identified  during  testing  have  been  resolved 
appropriately,  with  product  revisions,  if  necessary. 
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ACQUISITION  VALIDATION 


An  Acquisition  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Acquisition  Validation  (AVAL)  is  to  demonstrate  that  an 
acquired  product  or  service  fulfills  its  intended  use  when  placed  in  its 
intended  environment. 


Introductory  Notes 


Validation  demonstrates  that  the  acquired  product  or  service,  as 
provided,  will  fulfill  its  intended  use.  In  other  words,  validation  ensures 
that  the  acquired  product  or  service  meet  the  stakeholders’  intensions 
and  customer  requirements. 

Validation  activities  are  performed  early  and  incrementally  throughout 
the  project  lifecycle.  They  can  be  applied  to  all  aspects  of  the  product  in 
any  of  its  intended  environments,  such  as  operation,  training, 
manufacturing,  maintenance,  and  support  services.  The  methods 
employed  to  accomplish  validation  can  be  applied  to  acquirer  work 
products  such  as  customer  requirements  and  supplier  deliverables,  for 
example,  prototypes  developed  by  the  supplier  as  well  as  to  the 
acquired  product  and  service.  The  acquirer  work  products  and  supplier 
deliverables  should  be  selected  on  the  basis  of  which  are  the  best 
predictors  of  how  well  the  acquired  product  or  service  will  satisfy 
stakeholder  intentions. 

Whenever  possible,  validation  should  be  accomplished  using  the 
product  operating  in  its  intended  environment.  The  entire  environment 
can  be  used  or  only  part  of  it.  The  validation  environment  therefore 
needs  to  represent  the  intended  environment  for  the  product  or  service 
as  well  as  represent  the  intended  environment  suitable  for  validation 
activities  with  acquirer  work  products  or  supplier  deliverables. 

When  validation  issues  are  identified,  they  are  referred  to  the  processes 
associated  with  the  Acquisition  Requirements  Development  or  Project 
Monitoring  and  Control  process  areas  for  resolution. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Products  for  Validation  specific  practice  enables  the 
identification  of  the  product  or  product  component  to  be  validated 
and  the  methods  to  be  used  to  perform  the  validation. 


98 


Acquisition  Validation 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


•  The  Establish  the  Validation  Environment  specific  practice  enables 
the  determination  of  the  environment  that  will  be  used  to  carry  out 
the  validation. 

•  The  Establish  Validation  Procedures  and  Criteria  specific  practice 
enables  the  development  of  validation  procedures  and  criteria  that 
are  aligned  with  the  characteristics  of  selected  products,  customer 
constraints  on  validation,  methods,  and  the  validation  environment. 

•  The  Perform  Validation  specific  practice  enables  the  performance  of 
validation  according  to  the  methods,  procedures,  and  criteria. 

Related  Process  Areas 


Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  requirements  validation. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Validation 

SP  1 . 1  Select  Products  for  Validation 
SP  1 .2  Establish  the  Validation  Environment 
SP  1 .3  Establish  Validation  Procedures  and  Criteria 
SG  2  Validate  Products  or  Services 
SP2.1  Perform  Validation 
SP  2.2  Analyze  Validation  Results 


Specific  Practices  by  Goal 


SGI  Prepare  for  Validation 

Preparation  for  validation  is  conducted. 

Preparation  activities  include  selecting  products  and  product 
components  for  validation  and  establishing  and  maintaining  the 
validation  environment,  procedures,  and  criteria.  The  items  selected  for 
validation  may  include  only  the  acquired  product  or  it  may  include 
appropriate  levels  of  the  product  components  that  are  used  by  the 
supplier  to  build  the  product.  Any  product  or  product  component  may  be 
subject  to  validation,  including  replacement,  maintenance,  and  training 
products,  to  name  a  few. 

The  environment  required  to  validate  the  product  or  product  component 
is  prepared.  The  environment  may  be  purchased  or  may  be  specified, 
designed,  and  built.  The  environments  used  for  verification  may  be 
considered  in  collaboration  with  the  validation  environment  to  reduce 
cost  and  improve  efficiency  or  productivity. 
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SP  1.1  Select  Products  for  Validation 

Select  products  or  services  to  be  validated  and  the  validation 
methods  that  will  be  used  for  each. 


Products  or  services  are  selected  for  validation  on  the  basis  of  their 
relationship  to  stakeholder  intensions  and  customer  requirements.  For 
each  product  or  service,  the  scope  of  the  validation  (e.g.,  operational 
behavior,  maintenance,  training,  and  user  interface)  should  be 
determined. 


Examples  of  products  and  product  components  that  can  be  validated  include  the 
following: 

•  Customer  requirements  and  design  constraints 

•  Acquired  product  and  product  components  (e.g.,  system,  hardware  units,  software, 
service  documentation) 

•  User  manuals 

•  Training  materials 

•  Process  documentation 


Validation  methods  should  be  selected  early  in  the  life  of  the  project  so 
that  they  are  clearly  understood  and  agreed  to  by  the  relevant 
stakeholders. 

The  validation  methods  address  the  development,  maintenance, 
support,  and  training  for  the  product  or  product  component  as 
appropriate. 


Examples  of  validation  methods  include  the  following: 

•  Discussions  with  the  users,  perhaps  in  the  context  of  a  formal  review 

•  Prototype  demonstrations 

•  Functional  demonstrations  (e.g.,  system,  hardware  units,  software,  service 
documentation,  user  interfaces) 

•  Pilots  of  training  materials 

•  Acceptance  test  of  products  and  product  components  by  end  users  and  other 
relevant  stakeholders 

•  In  the  supplier  agreement,  expectations  of  suppliers  for  participation  in  validation  of 
product  and  product  components  are  captured. 


Typical  expectations  built  into  the  supplier  agreement  include  the 
following: 

•  List  of  acquired  products  that  need  validation  by  the  acquirer  before 
formal  acceptance 
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•  List  of  products  that  must  be  validated  with  customer,  users,  or 
other  stakeholders  by  the  supplier  and  applicable  validation 
standards,  procedures,  methods,  tools  and  criteria,  if  any. 

•  Measurements  to  be  collected  and  provided  by  the  supplier  with 
regard  to  validation  activities 

Typical  Acquirer  Work  Products 

1 .  Lists  of  products  or  services  selected  for  validation 

2.  Validation  methods  for  each  product  or  service 

3.  Requirements  for  performing  validation  for  each  product  or  service 

4.  Validation  constraints  for  each  product  or  service 

Subpractices 

1 .  Identify  the  key  principles,  features,  and  phases  for  product  or 
service  validation  throughout  the  life  of  the  project. 

2.  Determine  which  customer  requirements  are  to  be  validated. 

The  product  or  product  component  must  be  maintainable  and  supportable  in  its 
intended  environment.  This  specific  practice  also  addresses  the  actual 
maintenance,  training,  and  support  services  that  may  be  delivered  along  with  the 
product. 

3.  Select  the  product  or  service  to  be  validated. 

4.  Select  the  evaluation  methods  for  product  or  service  validation. 

5.  Review  the  validation  selection,  constraints,  and  methods  with 
relevant  stakeholders. 

SP  1.2  Establish  the  Validation  Environment 

Establish  and  maintain  the  environment  needed  to  support 
validation. 


The  requirements  for  the  validation  environment  are  driven  by  the 
product  or  service  selected,  by  the  type  of  the  work  products  (e.g., 
design,  prototype,  final  version),  and  by  the  methods  of  validation. 
These  may  yield  requirements  for  the  purchase  or  development  of 
equipment,  software,  or  other  resources.  The  validation  environment 
may  include  the  reuse  of  existing  resources.  In  this  case,  arrangements 
for  the  use  of  these  resources  must  be  made.  Examples  of  the  type  of 
elements  in  a  validation  environment  include  the  following: 

•  Test  tools  interfaced  with  the  product  being  validated  (e.g.,  scope, 
electronic  devices,  probes) 

•  Temporary  embedded  test  software 

•  Recording  tools  for  dump  or  further  analysis  and  replay 
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•  Simulated  subsystems  or  components  (by  software,  electronics,  or 
mechanics) 

•  Simulated  interfaced  systems  (e.g.,  a  dummy  warship  for  testing  a 
naval  radar) 

•  Real  interfaced  systems  (e.g.,  aircraft  for  testing  a  radar  with 
trajectory  tracking  facilities) 

•  Facilities  and  customer-supplied  products 

•  The  skilled  people  to  operate  or  use  all  the  preceding  elements 

•  Dedicated  computing  or  network  test  environment  (e.g.,  pseudo- 
operational  telecommunications-network  testbed  or  facility  with 
actual  trunks,  switches,  and  systems  established  for  realistic 
integration  and  validation  trials) 

Early  selection  of  the  products  or  service  to  be  validated,  the  work 
products  to  be  used  in  the  validation,  and  the  validation  methods  assure 
that  the  validation  environment  will  be  available  when  necessary. 

The  validation  environment  should  be  carefully  controlled  to  provide  for 
replication,  analysis  of  results,  and  revalidation  of  problem  areas. 

Typical  Acquirer  Work  Products 

1.  Validation  environment 

Typical  Supplier  Deliverable 
1.  Validation  environment 

Subpractices 

1 .  Identify  validation  environment  requirements. 

2.  Identify  customer-supplied  products. 

3.  Identify  reuse  items. 

4.  Identify  validation  equipment  and  tools. 

5.  Identify  validation  resources  that  are  available  for  reuse  and 
modification. 

6.  Plan  the  availability  of  resources  in  detail. 


SP  1.3  Establish  Validation  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  validation. 


Validation  procedures  and  criteria  are  defined  to  ensure  that  the  product 
or  product  component  will  fulfill  its  intended  use  when  placed  in  its 
intended  environment.  The  validation  procedures  and  criteria  include 
validation  of  maintenance,  training,  and  support  services. 
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They  also  address  validation  of  requirements  and  the  acquired  product 
or  service  throughout  the  project  life  cycle.  Typically,  formal  user 
acceptance  testing  procedures  and  criteria  are  established  to  ensure 
the  delivered  product  or  service  meets  stakeholder  intentions  before  it  is 
deployed  in  the  intended  environment. 

The  validation  procedures  and  criteria  applicable  to  the  supplier  are 
typically  referenced  in  the  solicitation  package  and  supplier  agreement. 


Examples  of  sources  for  validation  criteria  include  the  following: 

•  Business  process  descriptions 

•  Customer  requirements 

•  Acceptance  criteria 

•  Standards 


Typical  Acquirer  Work  Products 

1.  Validation  procedures 

2.  Validation  criteria 

3.  Test  and  evaluation  procedures  for  maintenance,  training,  and 
support 

Subpractices 

1 .  Review  the  customer  requirements  to  ensure  that  issues  affecting 
validation  of  the  acquired  product  or  service  are  identified  and 
resolved. 

2.  Document  the  environment,  operational  scenario,  procedures, 
inputs,  outputs,  and  criteria  for  the  validation  of  the  acquired 
product  or  service. 

3.  Assess  the  product  or  service  as  it  matures  in  the  context  of  the 
validation  environment  to  identify  validation  issues. 


SG  2  Validate  Products  or  Services 

The  products  or  services  are  validated  to  ensure  that  they  are  suitable  for 
use  in  their  intended  environment. 

The  validation  methods,  procedures,  and  criteria  are  used  to  validate 
the  selected  products  and  product  components  and  any  associated 
maintenance,  training,  and  support  services  using  the  appropriate 
validation  environment.  Validation  activities  are  performed  throughout 
the  project  lifecycle. 

SP  2.1  Perform  Validation 

Perform  validation  on  the  selected  products  or  services. 
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To  be  acceptable  to  stakeholders,  a  product  or  service  must  perform  as 
expected  in  its  intended  environment. 

Validation  activities  are  performed  and  the  resulting  data  are  collected 
according  to  the  established  methods,  procedures,  and  criteria. 

The  as-run  validation  procedures  should  be  documented  and  the 
deviations  occurring  during  the  execution  should  be  noted,  as 
appropriate. 

Typical  Acquirer  Work  Products 

1 .  Validation  reports 

2.  Validation  results 

3.  Validation  cross-reference  matrix 

4.  As-run  procedures  log 

5.  Operational  demonstrations 


SP  2.2  Analyze  Validation  Results 

Analyze  the  results  of  the  validation  activities. 


The  data  resulting  from  validation  tests,  inspections,  demonstrations,  or 
evaluations  are  analyzed  against  the  defined  validation  criteria.  Analysis 
reports  indicate  whether  the  stakeholders’  intentions  were  met;  in  the 
case  of  deficiencies,  these  reports  document  the  degree  of  success  or 
failure  and  categorize  probable  cause  of  failure.  The  collected  test, 
inspection,  or  review  results  are  compared  with  established  acceptance 
criteria  to  determine  whether  to  proceed  or  to  address  requirements  or 
design  issues  in  the  requirements  development  or  technical  solution 
processes. 

Analysis  reports  or  as-run  validation  documentation  may  also  indicate 
that  bad  test  results  are  due  to  a  validation  procedure  problem  or  a 
validation  environment  problem. 

Typical  Acquirer  Work  Products 

1.  Validation  deficiency  reports 

2.  Validation  issues 

3.  Procedure  change  request 

Subpractices 

1 .  Compare  actual  results  to  expected  results. 
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2.  Based  on  the  established  validation  criteria,  identify  products  and 
product  components  that  do  not  perform  suitably  in  their  intended 
operating  environments,  or  identify  problems  with  the  methods, 
criteria,  and/or  environment. 

3.  Analyze  the  validation  data  for  defects. 

4.  Record  the  results  of  the  analysis  and  identify  issues. 

5.  Use  validation  results  to  compare  actual  measurements  and 
performance  to  intended  use  or  operational  need. 

6.  Identify,  document,  and  track  action  items  to  closure  for  any  work 
products  that  do  not  pass  their  validation  procedures  and  criteria. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items. 
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ACQUISITION  VERIFICATION 


An  Acquisition  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Acquisition  Verification  (AVER)  is  to  ensure  that 
selected  work  products  meet  their  contractual  requirements. 


Introductory  Notes 


Acquisition  verification  addresses  whether  the  acquired  product, 
intermediate  acquirer  work  products,  and  supplier  deliverables  properly 
reflects  the  contractual  requirements. 

The  Acquisition  Verification  process  area  involves  the  following: 
verification  preparation,  verification  performance,  and  identification  of 
corrective  action. 

Verification  is  inherently  an  incremental  process  because  it  occurs 
throughout  the  acquisition  of  the  product  or  service,  beginning  with 
verification  of  the  requirements  and  plans,  progressing  through  the 
verification  of  the  evolving  work  products  such  as  design  and  test 
results,  and  culminating  in  the  verification  of  the  completed  product. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Work  Products  for  Verification  specific  practice  enables 
the  identification  of  the  work  products  to  be  verified,  the  methods  to 
be  used  to  perform  the  verification,  and  the  documented 
requirements  to  be  satisfied  by  each  selected  work  product. 

•  The  Establish  the  Verification  Environment  specific  practice  enables 
the  determination  of  the  environment  that  will  be  used  to  carry  out 
the  verification. 

•  The  Establish  Verification  Procedures  and  Criteria  specific  practice 
then  enables  the  development  of  verification  procedures  and  criteria 
that  are  aligned  with  the  selected  work  products,  requirements, 
methods,  and  characteristics  of  the  verification  environment. 

•  The  Perform  Verification  specific  practice  conducts  the  verification 
according  to  the  available  methods,  procedures,  and  criteria. 
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Peer  reviews  are  an  important  method  for  verification  of  work  products 
and  are  a  proven  mechanism  for  effective  defect  removal.  An  important 
corollary  is  to  develop  a  better  understanding  of  the  work  products  and 
the  processes  that  produced  them  so  that  defects  can  be  prevented  and 
process  improvement  opportunities  can  be  identified. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers’  peers  to  identify  defects  and  other  changes  that  are  needed. 


Examples  of  peer  review  methods  include  the  following: 

•  Inspections 

•  Structured  walkthroughs 


Related  Process  Areas 


Refer  to  the  Acquisition  Validation  process  area  for  more  information 
about  confirming  that  a  product  or  product  component  fulfills  its 
intended  use  when  placed  in  its  intended  environment. 

Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  the  generation  and  development  of  customer 
and  contractual  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Verification 

SP  1 .1  Select  Work  Products  for  Verification 
SP  1 .2  Establish  the  Verification  Environment 
SP  1 .3  Establish  Verification  Procedures  and  Criteria 
SG  2  Verify  Selected  Work  Products 
SP2.1  Perform  Verification 

SP  2.2  Analyze  Verification  Results  and  Identify  Corrective 
Action 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Verification 

Preparation  for  verification  is  conducted. 

Up-front  preparation  is  necessary  to  ensure  that  verification  provisions 
are  embedded  in  the  contractual  requirements,  constraints,  plans,  and 
schedules.  Verification  includes  selection,  inspection,  testing,  analysis, 
and  demonstration  of  acquirer  work  products  and  supplier  deliverables. 
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Methods  of  verification  include,  but  are  not  limited  to,  inspections,  peer 
reviews,  audits,  walkthroughs,  analyses,  simulations,  testing,  and 
demonstrations. 

Preparation  also  entails  the  definition  of  support  tools,  test  equipment 
and  software,  simulations,  prototypes,  and  facilities. 

SP  1.1  Select  Work  Products  for  Verification 

Select  the  work  products  to  be  verified  and  the  verification 
methods  that  will  be  used  for  each. 


Acquirer  work  products  are  selected  based  on  their  contribution  to 
meeting  project  objectives  and  requirements,  and  to  addressing  project 
risks. 

The  acquirer  selects  supplier  deliverables  for  which  the  supplier  must 
provide  verification  records.  The  required  methods  and  criteria  for  these 
work  products  are  described  in  the  supplier  agreement. 

Verification  can  be  performed  by  the  project,  as  contrasted  to  Product 
and  Process  Quality  Assurance,  which  is  performed  by  an  individual  or 
group  independent  of  the  project. 

Typical  acquirer  verification  activities  include  review  of  the  solicitation 
package,  supplier  agreements  and  plans,  requirements  documents,  and 
design  constraints  developed  by  the  acquirer. 

Selection  of  the  verification  methods  typically  begins  with  involvement  in 
the  definition  of  contractual  requirements  to  ensure  that  these 
requirements  are  verifiable.  Re-verification  should  be  addressed  by  the 
verification  methods  to  ensure  that  rework  performed  on  work  products 
does  not  cause  unintended  defects.  Suppliers  should  be  involved  in  this 
selection  to  ensure  that  the  project’s  methods  are  appropriate  for  the 
supplier’s  environment. 

Typical  Acquirer  Work  Products 

1 .  Lists  of  work  products  selected  for  verification 

2.  Verification  methods  for  each  selected  work  product 
Typical  Supplier  Deliverables 

1.  List  of  supplier  deliverables 

Subpractices 

1 .  Identify  acquirer  work  products  for  verification. 

2.  Identify  the  requirements  to  be  satisfied  by  each  selected  work 
product. 
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Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements 
specific  practice  in  the  Requirements  Management  process  area  to 
help  identify  the  requirements  for  each  work  product. 

3.  Identify  the  verification  methods  that  are  available  for  use. 

4.  Define  the  verification  methods  to  be  used  for  each  selected  work 
product. 

5.  Include  verification  activities  and  methods  to  be  used  in  the  project 
plan. 

Refer  to  the  Project  Planning  process  area  for  information  about 
coordinating  with  project  planning. 

6.  Establish  in  the  supplier  agreement  expectations  of  supplier  for 
verification  of  supplier  deliverables. 


Typical  expectations  for  verification  addressed  in  or  referenced  by  the  supplier 
agreement  include  the  following: 

•  List  of  deliverables  and  other  work  products  that  must  be  verified  by  the  supplier 

•  Applicable  standards,  procedures,  methods,  tools 

•  Criteria  for  verification  of  supplier  work  products,  if  any 

•  Measurements  to  be  collected  and  provided  by  the  supplier  with  regard  to 
verification  activities 

•  Reviews  of  supplier  verification  results  and  corrective  actions  with  the  acquirer 


SP  1.2  Establish  the  Verification  Environment 

Establish  and  maintain  the  environment  needed  to  support 
verification. 


An  environment  must  be  established  to  enable  verification  to  take  place. 
The  type  of  environment  required  will  depend  on  the  work  products 
selected  for  verification  and  the  verification  methods  used.  A  peer 
review  may  require  little  more  than  a  package  of  materials,  reviewers, 
and  a  room.  A  product  test  may  require  simulators,  emulators,  scenario 
generators,  data  reduction  tools,  environmental  controls,  and  interfaces 
with  other  systems. 

The  verification  environment  may  be  acquired,  developed,  reused, 
modified,  ora  combination  of  these,  depending  on  the  needs  of  the 
project. 

Typical  Acquirer  Work  Products 
1.  Verification  environment 

Subpractices 

1 .  Identify  verification  environment  requirements. 
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2.  Identify  verification  resources  that  are  available  for  reuse  and 
modification. 

3.  Identify  verification  equipment  and  tools. 

4.  Acquire  verification  support  equipment  and  an  environment,  such 
as  test  equipment  and  software. 

SP  1.3  Establish  Verification  Procedures  and  Criteria 

Establish  and  maintain  verification  procedures  and  criteria  for 
the  selected  work  products. 

Verification  criteria  are  defined  to  ensure  that  the  work  products  meet 
their  requirements. 

:  Examples  of  sources  for  verification  criteria  include  the  following: 

i  •  Product  and  product-component  requirements 
i  •  Standards 

i  •  Organizational  policies 

i  •  Test  type 

i  •  Test  parameters 

I  •  Parameters  for  tradeoff  between  quality  and  cost  of  testing 

:  •  Type  of  work  products 
•  Suppliers 


The  verification  procedures  and  criteria  are  typically  included  in  the 

solicitation  package  and  supplier  agreement. 

Typical  Acquirer  Work  Products 

1.  Verification  procedures 

2.  Verification  criteria 

Subpractices 

1 .  Generate  the  set  of  comprehensive,  integrated  verification 
procedures  for  work  products  and  any  commercial  off-the-shelf 
products,  as  necessary. 

2.  Develop  and  refine  the  verification  criteria  when  necessary. 

3.  Identify  the  expected  results,  any  tolerances  allowed  in 
observation,  and  other  criteria  for  satisfying  the  requirements. 

4.  Identify  any  equipment  and  environmental  components  needed  to 
support  verification. 
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5.  Establish  in  the  supplier  agreement  the  verification  methods  such 
as  acceptance  criteria  for  supplier  deliverables  and  other  work 
products. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  use  of  measurements. 

6.  Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new 
requirements. 

These  criteria  may  be  defined  by  the  acquirer  for  critical  supplier  work  products 
only,  as  identified  under  the  Select  Work  Products  For  Verification  practice. 

The  peer  review  is  an  important  and  effective  engineering  method  implemented 
via  inspections,  structured  walkthroughs,  or  a  number  of  other  collegial  review 
methods. 


SG  2  Verify  Selected  Work  Products 

Selected  work  products  are  verified  against  their  contractual 
requirements. 

The  verification  methods,  procedures,  and  criteria  are  used  to  verify  the 
selected  work  products  and  any  associated  maintenance,  training,  and 
support  services  using  the  appropriate  verification  environment. 
Verification  activities  should  be  performed  throughout  the  project 
lifecycle. 


SP  2.1  Perform  Verification 

Perform  verification  on  the  selected  work  products. 

Verifying  acquired  products  and  work  products  incrementally  promotes 
early  detection  of  problems  and  can  result  in  the  early  removal  of 
defects.  The  results  of  verification  save  considerable  cost  of  fault 
isolation  and  rework  associated  with  troubleshooting  problems. 

Typical  Acquirer  Work  Products 

1 .  Verification  results 

2.  Verification  reports 

3.  Demonstrations 

4.  As-run  procedures  log 

Typical  Supplier  Deliverables 

1 .  Verification  results 

2.  Verification  reports 


Acquisition  Verification 


111 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Subpractices 

1 .  Perform  verification  of  selected  work  products  against  their 
requirements. 

2.  Record  the  results  of  verification  activities. 

3.  Identify  action  items  resulting  from  verification  of  work  products. 

4.  Document  the  “as-run”  verification  method  and  the  deviations  from 
the  available  methods  and  procedures  discovered  during  its 
performance. 

5.  Review  critical  verification  results  and  data  for  verifications 
conducted  by  the  supplier. 

SP  2.2  Analyze  Verification  Results 

Analyze  the  results  of  all  verification  activities. 


Actual  results  must  be  compared  to  established  verification  criteria  to 
determine  acceptability. 

The  results  of  the  analysis  are  recorded  as  evidence  that  verification 
was  conducted. 

For  each  work  product,  all  available  verification  results  are 
incrementally  analyzed  and  corrective  actions  are  initiated  to  ensure 
that  the  documented  requirements  have  been  met  for  both  acquirer  and 
supplier.  Corrective  actions  are  typically  integrated  into  project 
monitoring  activities.  Since  a  peer  review  is  one  of  several  verification 
methods,  peer  review  data  should  be  included  in  this  analysis  activity  to 
ensure  that  the  verification  results  are  analyzed  sufficiently.  Analysis 
reports  or  “as-run”  method  documentation  may  also  indicate  that  bad 
verification  results  are  due  to  method  problems,  criteria  problems,  or  a 
verification  environment  problem. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
on  corrective  actions. 

Typical  Acquirer  Work  Products 

1.  Analysis  report  (e.g.,  statistics  on  performances,  causal  analysis  of 
nonconformances,  comparison  of  the  behavior  between  the  real 
product  and  models,  and  trends) 

2.  Trouble  reports 

3.  Change  requests  for  the  verification  methods,  criteria,  and 
environment 

Subpractices 

1 .  Compare  actual  results  to  expected  results. 
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2.  Based  on  the  established  verification  criteria,  identify  products  that 
have  not  met  their  requirements  or  identify  problems  with  the 
methods,  procedures,  criteria,  and  verification  environment 

3.  Analyze  the  verification  data  on  defects. 

4.  Record  all  results  of  the  analysis  in  a  report. 

5.  Use  verification  results  to  compare  actual  measurements  and 
performance  to  technical  performance  parameters. 

6.  Provide  information  on  how  defects  can  be  resolved  (including 
verification  methods,  criteria,  and  verification  environment)  and 
formalize  it  in  a  plan. 
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CAUSAL  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Causal  Analysis  and  Resolution  (CAR)  is  to  identify 
causes  of  defects  and  other  problems  and  take  action  to  prevent  them 
from  occurring  in  the  future. 


Introductory  Notes 


The  Causal  Analysis  and  Resolution  process  area  involves  the 
following: 

•  Identifying  and  analyzing  causes  of  defects  and  other  problems 

•  Taking  specific  actions  to  remove  the  causes  and  prevent  the 
occurrence  of  those  types  of  defects  and  problems  in  the  future 

Causal  analysis  and  resolution  improves  quality  and  productivity  by 
preventing  the  introduction  of  defects  into  a  product.  Reliance  on 
detecting  defects  after  they  have  been  introduced  is  not  cost  effective.  It 
is  more  effective  to  prevent  defects  from  being  introduced  by  integrating 
causal  analysis  and  resolution  activities  into  each  phase  of  the  project. 

Since  defects  and  problems  may  have  been  previously  encountered  on 
other  projects  or  in  earlier  phases  or  tasks  of  the  current  project,  causal 
analysis  and  resolution  activities  are  a  mechanism  for  communicating 
lessons  learned  among  projects. 

The  types  of  defects  and  other  problems  encountered  are  analyzed  to 
identify  any  trends.  Based  on  an  understanding  of  the  defined  process 
and  how  it  is  implemented,  the  root  causes  of  the  defects  and  the  future 
implications  of  the  defects  are  determined. 

Causal  analysis  may  also  be  performed  on  problems  unrelated  to 
defects.  For  example,  causal  analysis  may  be  used  to  improve 
coordination  and  cycle  time  with  one  supplier  or  multiple  suppliers,  [acq] 

Sometimes  it  may  be  impractical  to  perform  causal  analysis  on  all 
defects.  In  these  cases,  tradeoffs  are  made  between  estimated 
investments  and  estimated  returns  in  quality,  productivity,  and  cycle 
time,  and  defect  targets  are  selected. 
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A  measurement  process  should  already  be  in  place.  The  defined 
measures  can  be  used,  though  in  some  instances  new  measures  may 
be  needed  to  analyze  the  effects  of  the  process  change. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

Causal  Analysis  and  Resolution  activities  provide  a  mechanism  for 
projects  to  evaluate  their  processes  at  the  local  level  and  look  for 
improvements  that  can  be  implemented. 

Causal  Analysis  and  Resolution  activities  also  include  the  evaluation  of 
supplier’s  processes  that  interface  with  the  acquirer’s  processes,  as 
appropriate.  Root  causes  may  cause  the  supplier  to  improve  its 
processes  to  more  effectively  execute  in  the  context  of  the  project  or  it 
might  cause  the  acquirer  to  improve  its  supplier  interfaces,  [acq] 

When  improvements  are  judged  to  be  effective,  the  information  is 
extended  to  the  organizational  level. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  organizational  level  processes 
through  proposed  improvements  and  action  proposals. 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  the  assumption  is  not  met. 

See  the  definitions  of  “stable  process”  and  “common  cause  of  process 
variation”  in  the  glossary. 


Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  analysis  of  process  performance  and  the  creation 
of  process  capability  measures  for  selected  project  processes. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  the  selection  and  deployment  of 
improvements  to  organizational  processes  and  technologies. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 
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Specific  Goal  and  Practice  Summary 

SG  1  Determine  Causes  of  Defects 

SP  1 .1  Select  Defect  Data  for  Analysis 
SP1.2  Analyze  Causes 
SG  2  Address  Causes  of  Defects 

SP  2.1  Implement  the  Action  Proposals 
SP  2.2  Evaluate  the  Effect  of  Changes 
SP  2.3  Record  Data 


Specific  Practices  by  Goal 


SG  1  Determine  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  determined. 

A  root  cause  is  a  source  of  a  defect  such  that  if  it  is  removed,  the  defect 
is  decreased  or  removed. 

SP  1 .1  Select  Defect  Data  for  Analysis 

Select  the  defects  and  other  problems  for  analysis. 


Typical  Acquirer  Work  Products 

1 .  Defect  and  problem  data  selected  for  further  analysis 
Subpractices 

1 .  Gather  relevant  defect  or  problem  data. 

Examples  of  relevant  defect  data  may  include  the  following:  iacqi 

i  •  Defects  reported  by  the  customer  i 

i  •  Defects  reported  by  end  user  j 

J  ! 

:  •  Defects  reported  by  the  supplier 

;  Examples  of  relevant  problem  data  may  include  the  following:  [acqi 

:  •  Project-management  problem  reports  requiring  corrective  action 
i  •  Process  capability  problems  j 

j  •  Process  duration  measurements  j 

j  •  Earned  value  measurements  by  process  (e.g.,  cost  performance  index) 

•  Resource  throughput,  utilization,  or  response  time  measurements 

Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  statistical  management. 

2.  Determine  which  defects  and  other  problems  will  be  analyzed 
further. 
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When  determining  which  defects  to  analyze  further,  consider  the  impact  of  the 
defects,  the  frequency  of  occurrence,  the  similarity  between  defects,  the  cost  of 
analysis,  the  time  and  resources  needed,  the  safety  considerations,  etc.  [acqi 


Examples  of  methods  for  selecting  defects  and  other  problems  include  the 
following:  [acq] 

•  Pareto  analysis 

•  Histograms 

•  Process  capability  analysis 


SP  1.2  Analyze  Causes 

Perform  causal  analysis  of  selected  defects  and  other  problems 
and  propose  actions  to  address  them. 


The  purpose  of  this  analysis  is  to  develop  solutions  to  the  identified 
problems  by  analyzing  the  relevant  data  and  producing  action  proposals 
for  implementation. 

Typical  Acquirer  Work  Products 

1 .  Action  proposal 

2.  Root  cause  analysis  results  [acq] 

Typical  Supplier  Deliverables 

1 .  Root  cause  analysis  results  [acq] 

2.  Recommended  action  proposals  [acq] 

Subpractices 

1 .  Conduct  causal  analysis  with  the  people  who  are  responsible  for 
performing  the  task. 

Causal  analysis  is  performed  with  those  people  who  have  an  understanding  of  the 
selected  defect  or  problem  under  study,  typically  in  meetings.  The  people  who 
have  the  best  understanding  of  the  selected  defect  are  typically  those  responsible 
for  performing  the  task. 


Examples  of  when  to  perform  causal  analysis  include  the  following:  [acqi 

•  When  a  stable  process  does  not  meet  its  specified  quality  and  process- 
performance  objectives 

•  During  the  task,  if  and  when  problems  warrant  additional  meetings 

•  When  a  work  product  exhibits  an  unexpected  deviation  from  its  requirements 
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Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  achieving  the  project’s  quality  and  process- 
performance  objectives. 

2.  Analyze  selected  defects  and  other  problems  to  determine  their 
root  causes. 

Depending  on  the  type  and  number  of  defects,  it  may  make  sense  to  first  group 
the  defects  before  identifying  their  root  causes. 

:  Examples  of  methods  to  determine  root  causes  include  the  following:  [acqi 

|  •  Cause-and-effect  (fishbone)  diagrams 
:  •  Check  sheets 

3.  Group  the  selected  defects  and  other  problems  based  on  their  root 
causes. 

:  Examples  of  cause  groups,  or  categories,  include  the  following:  [acqi 

i  •  Inadequate  training 

|  •  Breakdown  of  communications 

:  •  Not  accounting  for  all  details  of  the  task 

i  •  Making  mistakes  in  manual  procedures  (e.g.,  typing) 

j  •  Process  deficiency 

|  •  Incomplete,  ambiguous,  or  unclear  contractual  requirements 
:  •  Ineffective  management  of  changes  to  the  supplier  agreement 

4.  Propose  and  document  actions  that  need  to  be  taken  to  prevent 
the  future  occurrence  of  similar  defects  or  other  problems. 

Examples  of  proposed  actions  include  changes  to  the  following:  [acqi 

i  •  The  process  in  question 
|  •  Training 
|  •  Tools 
:  •  Methods 
i  •  Communications 
:  •  Work  products 
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Examples  of  specific  actions  include  the  following:  [acqi 

•  Providing  training  in  common  problems  and  techniques  for  preventing  them 

•  Changing  a  process  so  that  error-prone  steps  do  not  occur 

•  Automating  all  or  part  of  a  process 

•  Reordering  process  activities 

•  Adding  process  steps  to  prevent  defects,  such  as  task  kickoff  meetings  to  review 
common  defects  and  actions  to  prevent  them 


An  action  proposal  usually  documents  the  following:  [acqi 

•  Originator  of  the  action  proposal 

•  Description  of  the  problem 

•  Description  of  the  defect  cause 

•  Defect  cause  category 

•  Phase  when  the  problem  was  introduced 

•  Phase  when  the  defect  was  identified 

•  Description  of  the  action  proposal 

•  Action  proposal  category 

SG  2  Address  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  addressed 
to  prevent  their  future  occurrence. 

Projects  operating  according  to  a  well-defined  process  will 
systematically  analyze  the  operation  where  problems  still  occur  and 
implement  process  changes  to  eliminate  root  causes  of  selected 
problems. 

SP  2.1  Implement  the  Action  Proposals 

Implement  the  selected  action  proposals  that  were  developed  in 
causal  analysis. 


Action  proposals  describe  the  tasks  necessary  to  remove  the  root 
causes  of  the  analyzed  defects  or  problems  and  avoid  their 
reoccurrence. 

Only  changes  that  prove  to  be  of  value  should  be  considered  for  broad 
implementation. 

Typical  Acquirer  Work  Products 

1 .  Action  proposals  selected  for  implementation 

2.  Improvement  proposals 
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Typical  Supplier  Deliverables 

1.  Improvement  proposals 

Subpractices 

1 .  Analyze  the  action  proposals  and  determine  their  priorities. 

Criteria  for  prioritizing  action  proposals  include  the  following:  [acqi 

•  Implications  of  not  addressing  the  defects 

•  Cost  to  implement  process  improvements  to  prevent  the  defects 

•  Expected  impact  on  quality 

2.  Select  the  action  proposals  that  will  be  implemented. 

3.  Create  action  items  for  implementing  the  action  proposals. 

!  Examples  of  information  provided  in  an  action  item  include  the  following:  [acqi 

:  •  Person  responsible  for  implementing  it 
i  •  Description  of  the  areas  affected  by  it 
|  •  People  who  are  to  be  kept  informed  of  its  status 
|  •  Next  date  that  status  will  be  reviewed 
:  •  Rationale  for  key  decisions 
i  •  Description  of  implementation  actions 
|  •  Time  and  cost  for  identifying  the  defect  and  correcting  it 
:  •  Estimated  cost  of  not  fixing  the  problem 

To  implement  the  action  proposals,  the  following  tasks  must  be  done:  [acqi 

•  Make  assignments 

•  Coordinate  the  persons  doing  the  work 

•  Review  the  results 

•  Track  the  action  items  to  closure 

Experiments  may  be  conducted  for  particularly  complex  changes. 

Examples  of  experiments  include  the  following:  [acqi 

i  •  Using  a  temporarily  modified  process 

•  Using  a  new  tool 

Action  items  may  be  assigned  to  members  of  the  causal  analysis  team,  members 
of  the  project  team,  or  other  members  of  the  organization,  [acqi 

4.  Identify  and  remove  similar  defects  that  may  exist  in  other 
processes  and  work  products. 
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5.  Identify  and  document  improvement  proposals  for  the 
organization’s  set  of  standard  processes. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  the  selection  and  deployment  of 
improvement  proposals  for  the  organization’s  set  of  standard 
processes. 


SP  2.2  Evaluate  the  Effect  of  Changes 

Evaluate  the  effect  of  changes  on  process  performance. 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  analyzing  process  performance  and  creating  process 
capability  measures  for  selected  processes. 

Once  the  changed  process  is  deployed  across  the  project,  the  effect  of 
the  changes  must  be  checked  to  gather  evidence  that  the  process 
change  has  corrected  the  problem  and  improved  performance. 

Typical  Acquirer  Work  Products 

1 .  Measures  of  performance  and  performance  change 
Typical  Supplier  Deliverables 

1 .  Base  and  derived  supplier  measurement  data  sets  [acq] 

Subpractices 

1 .  Measure  the  change  in  the  performance  of  the  project's  defined 
process  as  appropriate. 

This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  process  performance  and  by  how  much,  [acq] 

2.  Measure  the  capability  of  the  project's  defined  process  as 
appropriate. 

This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  ability  of  the  process  to  meet  its  quality  and  process-performance 
objectives,  as  determined  by  relevant  stakeholders,  [acq] 


An  example  of  a  change  in  the  capability  of  the  project’s  defined  change 
management  process  would  be  a  change  in  the  ability  of  the  process  to  stay 
within  its  process-specification  boundaries.  This  can  be  statistically  measured  by 
calculating  the  range  of  time  taken  for  processing  a  change  request  before  and 
after  the  improvement  has  been  made,  [acqi 
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SP  2.3  Record  Data 

Record  causal  analysis  and  resolution  data  for  use  across  the 
project  and  organization. 

Data  are  recorded  so  that  other  projects  and  organizations  can  make 
appropriate  process  changes  and  achieve  similar  results. 

Record  the  following: 

•  Data  on  defects  and  other  problems  that  were  analyzed 

•  Rationale  for  decisions 

•  Action  proposals  from  causal  analysis  meetings 

•  Action  items  resulting  from  action  proposals 

•  Cost  of  the  analysis  and  resolution  activities 

•  Measures  of  changes  to  the  performance  of  the  defined  process 
resulting  from  resolutions 

Typical  Acquirer  Work  Products 

1.  Causal  analysis  and  resolution  records 
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CONFIGURATION  MANAGEMENT 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Configuration  Management  (CM)  is  to  establish  and 
maintain  the  integrity  of  work  products  using  configuration  identification, 
configuration  control,  configuration  status  accounting,  and  configuration 
audits. 


Introductory  Notes 


The  Configuration  Management  process  area  involves  the  following: 

•  Identifying  the  configuration  of  selected  work  products  that  compose 
the  baselines  at  given  points  in  time 

•  Controlling  changes  to  configuration  items 

•  Building  or  providing  specifications  to  build  work  products  from  the 
configuration  management  system 

•  Maintaining  the  integrity  of  baselines 

•  Providing  accurate  status  and  current  configuration  data  to 
developers,  end  users,  and  customers 

The  work  products  placed  under  configuration  management  include  the 
products  that  are  delivered  to  the  customer,  designated  internal  work 
products,  acquired  products,  tools,  and  other  items  that  are  used  in 
creating  and  describing  these  work  products.  (See  the  definition  of 
“configuration  management”  in  the  glossary.) 

Acquired  products  may  need  to  be  placed  under  configuration 
management  by  both  the  supplier  and  the  project.  Provisions  for 
conducting  configuration  management  should  be  established  in  supplier 
agreements.  Methods  to  ensure  that  the  data  is  complete  and 
consistent  should  be  established  and  maintained. 

Planning  for  managing  configuration  items,  including  during  transition  to 
operations  and  support,  is  addressed  as  part  of  project  planning  to 
avoid  unexpected  costs  to  procure,  reformat,  and  deliver  configuration 
items  from  the  supplier.  Include  plans  for  managing  configuration  items 
within  the  project  teams  and  the  infrastructure  required  to  manage 
configuration  items  between  the  acquirer,  supplier,  operational  users, 
and  other  relevant  stakeholders,  [acq] 
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The  approach  for  configuration  management  depends  on  acquisition 
specific  factors  such  as  acquisition  approach,  number  of  suppliers, 
design  responsibility,  support  concept,  and  associated  costs  and  risks. 
In  any  case,  configuration  management  involves  interaction  between 
acquirer  and  supplier.  With  regard  to  the  technical  solution,  the  acquirer 
maintains  configuration  control  of  the  contractual  requirements  and  the 
supplier  performs  configuration  management  for  the  technical  solution 
(e.g.,  establish  and  maintain  product  baseline).  As  such,  the  acquirer 
retains  the  authority  and  responsibility  for  approving  any  design 
changes  that  impact  the  product’s  ability  to  meet  contractual 
requirements.  The  supplier  manages  other  design  changes.  The 
acquirer  maintains  the  right  to  access  configuration  data  at  any  level 
required  to  implement  planned  or  potential  design  changes  and  support 
options.  Configuration  management  of  legacy  systems  should  be 
addressed  on  a  case-by-case  basis  as  design  changes  are 
contemplated,  [acqj 


Examples  of  work  products  that  may  be  placed  under  configuration  management 
include  the  following:  [acqj 

•  Plans 

•  Process  descriptions 

•  Requirements 

•  Acquisition  strategy 

•  Solicitation  package 

•  Supplier  agreement 

•  Supplier  deliverables 


Configuration  management  of  work  products  may  be  performed  at 
several  levels  of  granularity.  Configuration  items  can  be  decomposed 
into  configuration  components  and  configuration  units.  Only  the  term 
“configuration  item”  is  used  in  this  process  area.  Therefore,  in  these 
practices,  “configuration  item”  may  be  interpreted  as  “configuration 
component”  or  “configuration  unit”  as  appropriate.  (See  the  definition  of 
“configuration  item”  in  the  glossary.) 

Baselines  provide  a  stable  basis  for  continuing  evolution  of 
configuration  items. 

An  example  of  an  acquirer’s  baseline  is  a  collection  of  acquirer  work 
products  such  as  contractual  requirements  and  acceptance  criteria  that 
are  related  to  the  product  baseline  managed  by  the  supplier,  [acq] 
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Baselines  are  added  to  the  configuration  management  system  as  they 
are  developed.  Changes  to  baselines  and  the  release  of  work  products 
built  from  the  configuration  management  system  are  systematically 
controlled  and  monitored  via  the  configuration  control,  change 
management,  and  configuration  auditing  functions  of  configuration 
management. 

This  process  area  applies  not  only  to  configuration  management  on 
projects,  but  also  to  configuration  management  on  organization  work 
products  such  as  standards,  procedures,  and  reuse  libraries. 

Configuration  management  is  focused  on  the  rigorous  control  of  the 
managerial  and  technical  aspects  of  work  products,  including  the 
delivered  system. 

This  process  area  covers  the  practices  for  performing  the  configuration 
management  function  and  is  applicable  to  all  work  products  that  are 
placed  under  configuration  management. 


Related  Process  Areas 


Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  information  on  defining  supplier  configuration  management 
responsibilities  in  the  supplier  agreement,  [acq] 

Refer  to  the  Acquisition  Management  process  area  for  information  on 
formal  acceptance  of  supplier  deliverables,  [acq] 

Refer  to  the  Project  Planning  process  area  for  information  on 
developing  plans  and  work  breakdown  structures,  which  may  be  useful 
for  determining  configuration  items. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  performance  analyses  and  corrective  actions. 
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Specific  Goal  and  Practice  Summary 

SG  1  Establish  Baselines 

SP1.1  Identify  Configuration  Items 
SP  1 .2  Establish  a  Configuration  Management  System 
SP  1 .3  Create  or  Release  Baselines 

SG  2  Track  and  Control  Changes 

SP  2.1  Track  Change  Requests 

SP  2.2  Control  Configuration  Items 

SG  3  Establish  Integrity 

SP  3.1  Establish  Configuration  Management  Records 

SP  3.2  Perform  Configuration  Audits 


Specific  Practices  by  Goal 


SG  1  Establish  Baselines 

Baselines  of  identified  work  products  are  established. 

Specific  practices  to  establish  baselines  are  covered  by  this  specific 
goal.  The  specific  practices  under  the  Track  and  Control  Changes 
specific  goal  serve  to  maintain  the  baselines.  The  specific  practices  of 
the  Establish  Integrity  specific  goal  document  and  audit  the  integrity  of 
the  baselines. 

SP  1.1  Identify  Configuration  Items 

Identify  the  configuration  items,  components,  and  related  work 
products  that  will  be  placed  under  configuration  management. 

Configuration  identification  is  the  selection,  creation,  and  specification 
of  the  following: 

•  Products  that  are  delivered  to  the  customer 

•  Designated  internal  work  products 

•  Acquired  products 

•  Tools  and  other  capital  assets  of  the  project’s  work  environment 

•  Other  items  that  are  used  in  creating  and  describing  these  work 
products 

Items  under  configuration  management  will  include  specifications  and 
interface  documents  that  define  the  requirements  for  the  product.  Other 
documents,  such  as  test  results,  may  also  be  included,  depending  on 
their  criticality  to  defining  the  product. 

A  “configuration  item”  is  an  entity  designated  for  configuration 
management,  which  may  consist  of  multiple  related  work  products  that 
form  a  baseline.  This  logical  grouping  provides  ease  of  identification 
and  controlled  access.  The  selection  of  work  products  for  configuration 
management  should  be  based  on  criteria  established  during  planning. 
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Configuration  items  may  vary  widely  in  complexity,  size,  and  type,  from 
an  aircraft,  commercial-of-the-shelf  software  to  a  test  meter  or  project 
plan.  Any  item  required  for  product  support  and  designated  for  separate 
procurement  is  a  configuration  item.  Acquirer  work  products  provided  to 
suppliers  such  as  solicitation  packages  and  technical  standards  are 
typically  designated  as  configuration  items,  [acq] 

Typical  Acquirer  Work  Products 

1.  Identified  configuration  items 

Subpractices 

1 .  Select  the  configuration  items  and  the  work  products  that  compose 
them  based  on  documented  criteria. 

Example  criteria  for  selecting  configuration  items  at  the  appropriate  work  product 
:  level  include  the  following:  [acqj 

|  •  Work  products  that  may  be  used  by  two  or  more  groups 

:  •  Work  products  that  are  expected  to  change  over  time  either  because  of  errors  or 
:  change  of  requirements 

i  •  Work  products  that  are  dependent  on  each  other  in  that  a  change  in  one 
i  mandates  a  change  in  the  others 

:  •  Work  products  that  are  critical  for  the  project 

.  Examples  of  acquirer  work  products  and  supplier  deliverables  that  may  be  part  of 
:  a  configuration  item  include  the  following:  [acqj 

|  •  Process  descriptions 
:  •  Requirements 
i  •  Acceptance  criteria 
|  •  Supplier  performance  measures 
•  Supplier  test  results 

2.  Assign  unique  identifiers  to  configuration  items. 

3.  Specify  the  important  characteristics  of  each  configuration  item. 

4.  Specify  when  each  configuration  item  is  placed  under  configuration 
management. 
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:  Example  criteria  for  determining  when  to  place  work  products  under  configuration 
:  management  include  the  following:  [acq] 

|  •  Stage  of  the  project  life  cycle 

:  •  When  the  acquirer  work  product  is  ready  for  review  and  approval 
i  •  Degree  of  control  desired  on  the  work  product 
j  •  Cost  and  schedule  limitations 
:  •  Customer  requirements^ 

5.  Identify  the  owner  responsible  for  each  configuration  item. 

SP  1.2  Establish  a  Configuration  Management  System 

Establish  and  maintain  a  configuration  management  and 
change  management  system  for  controlling  work  products. 

A  configuration  management  system  includes  the  storage  media,  the 
procedures,  and  the  tools  for  accessing  the  configuration  system. 

A  change  management  system  includes  the  storage  media,  the 
procedures,  and  tools  for  recording  and  accessing  change  requests. 

Consider  how  configuration  items  will  be  shared  between  acquirer  and 
supplier  as  well  as  across  relevant  stakeholders.  If  the  use  of  an 
acquirer’s  configuration  management  system  is  extended  to  a  supplier, 
security  and  access  control  procedures  must  be  exercised  by  the 
acquirer.  In  many  cases,  leaving  acquired  configuration  items  in  the 
physical  possession  of  the  supplier  and  having  access  to  supplier 
deliverables  is  an  alternative  solution.  The  supplier  agreement  specifies 
appropriate  acquirer  rights  to  the  supplier  deliverables,  in  addition  to 
requirements  for  delivery  or  access.  Supplier  work  products,  whenever 
they  are  delivered  to  the  acquirer,  are  formatted  in  accordance  with 
accepted  standards  to  ensure  usability  by  the  acquirer,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Configuration  management  system  with  controlled  work  products 

2.  Configuration  management  system  access  control  procedures 

3.  Change  request  database 

Subpractices 

1.  Establish  a  mechanism  to  manage  multiple  control  levels  of 
configuration  management. 
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The  level  of  control  is  typically  selected  based  on  project  objectives, 
risk,  and/or  resources.  Levels  of  control  can  range  from  informal  control 
that  simply  tracks  changes  made  when  the  configuration  items  are 
being  developed  by  the  acquirer  or  when  supplier  work  products  are 
delivered  or  made  accessible  to  the  acquirer  to  formal  configuration 
control  using  baselines  that  can  only  be  changed  as  part  of  a  formal 
configuration  management  process,  [acq] 

2.  Store  and  retrieve  configuration  items  in  configuration  management 
system. 

3.  Share  and  transfer  configuration  items  between  control  levels 
within  the  configuration  management  system. 

4.  Store  and  recover  archived  versions  of  configuration  items. 

5.  Store,  update,  and  retrieve  configuration  management  records. 

6.  Create  configuration  management  reports  from  the  configuration 
management  system. 

7.  Preserve  the  contents  of  the  configuration  management  system. 


Examples  of  preservation  functions  of  the  configuration  management  system 
include  the  following:  [acqj 

•  Backups  and  restoration  of  configuration  management  files 

•  Archiving  of  configuration  management  files 

•  Recovery  from  configuration  management  errors 


8.  Revise  the  configuration  management  structure  as  necessary. 

SP  1.3  Create  or  Release  Baselines 

Create  or  release  baselines  for  internal  use  and  for  delivery  to 
the  customer. 


A  baseline  is  a  set  of  specifications  or  work  products  that  has  been 
formally  reviewed  and  agreed  on,  that  thereafter  serves  as  the  basis  for 
further  development  or  delivery,  and  that  can  be  changed  only  through 
change  control  procedures.  A  baseline  represents  the  assignment  of  an 
identifier  to  a  configuration  item  or  a  collection  of  configuration  items 
and  associated  entities. 

The  acquirer  reviews  and  approves  the  release  of  the  product  baselines 
created  by  the  supplier.  The  acquirer  creates  baselines  for  acquirer 
work  products  to  mark  the  agreement  on  the  description  of  the  project, 
requirements,  funding,  schedule,  and  performance  parameters  and  to 
make  a  commitment  to  manage  the  program  to  those  baselines,  [acq] 
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Typical  Acquirer  Work  Products 

1.  Baselines 

2.  Description  of  baselines 

Typical  Supplier  Deliverables 

1 .  Product  baselines  [acqj 

2.  Description  of  product  baselines  [acq] 

Subpractices 

1.  Obtain  authorization  from  the  configuration  control  board  (CCB) 
before  creating  or  releasing  baselines  of  configuration  items. 

2.  Create  or  release  baselines  only  from  configuration  items  in  the 
configuration  management  system. 

3.  Document  the  set  of  configuration  items  that  are  contained  in  a 
baseline. 

4.  Make  the  current  set  of  baselines  readily  available. 


SG  2  Track  and  Control  Changes 

Changes  to  the  work  products  under  configuration  management  are 
tracked  and  controlled. 

The  specific  practices  under  this  specific  goal  serve  to  maintain  the 
baselines  after  they  are  established  by  the  specific  practices  under  the 
Establish  Baselines  specific  goal. 

SP  2.1  Track  Change  Requests 

Track  change  requests  for  the  configuration  items. 


Change  requests  address  not  only  new  or  changed  requirements,  but 
also  failures  and  defects  in  the  work  products. 

Change  requests  can  be  initiated  either  by  the  acquirer  or  the  supplier. 
Changes  that  impact  the  acquirer’s  work  products  and  supplier 
deliverables  as  defined  in  the  supplier  agreement  are  handled  through 
the  acquirer’s  configuration  management  process,  [acq] 

Change  requests  are  analyzed  to  determine  the  impact  that  the  change 
will  have  on  the  work  product,  related  work  products,  and  schedule  and 
cost. 

Typical  Acquirer  Work  Products 

1.  Change  requests 
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Subpractices 

1.  Initiate  and  record  change  requests  in  the  change  request 
database. 

2.  Analyze  the  impact  of  changes  and  fixes  proposed  in  the  change 
requests. 

The  acquirer  analyzes  what  impact  submitted  change  requests  have  on  the 
supplier  agreements,  [acq] 

Refer  to  the  Acquisition  Management  process  area  for  information 
about  changing  the  supplier  agreement,  [acqj 

3.  Review  change  requests  that  will  be  addressed  in  the  next  baseline 
with  the  relevant  stakeholders  and  get  their  agreement. 

Conduct  the  change  request  review  with  appropriate  participants.  Record  the 
disposition  of  each  change  request  and  the  rationale  for  the  decision,  including 
success  criteria,  a  brief  action  plan  if  appropriate,  and  needs  met  or  unmet  by  the 
change.  Perform  the  actions  required  in  the  disposition,  and  report  the  results  to 
relevant  stakeholders,  [acqi 

4.  Track  the  status  of  change  requests  to  closure. 

SP  2.2  Control  Configuration  Items 

Control  changes  to  the  configuration  items. 


Control  is  maintained  over  the  configuration  of  the  work  product 
baseline.  This  control  includes  tracking  the  configuration  of  each  of  the 
configuration  items,  approving  a  new  configuration  if  necessary,  and 
updating  the  baseline. 

Decide  which  configuration  items  require  version  control,  or  more 
stringent  levels  of  configuration  control,  and  establish  mechanisms  to 
ensure  configuration  items  are  controlled.  Although  the  supplier  may 
manage  configuration  items  on  the  acquirer’s  behalf,  the  acquirer  is 
responsible  for  approval  and  control  of  changes  to  such  configuration 
items,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Archives  of  the  baselines 
Subpractices 

1 .  Control  changes  to  configuration  items  throughout  the  life  of  the 
product. 
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2.  Obtain  appropriate  authorization  before  changed  configuration 
items  are  entered  into  the  configuration  management  system. 


For  example,  authorization  may  come  from  the  CCB,  the  project  manager,  or  the 
customer,  [acqi 


3.  Check  in  and  check  out  configuration  items  from  the  configuration 
management  system  for  incorporation  of  changes  in  a  manner  that 
maintains  the  correctness  and  integrity  of  the  configuration  items. 

4.  Perform  reviews  to  ensure  that  changes  have  not  caused 
unintended  effects  on  the  baselines  (e.g.,  ensure  that  the  changes 
have  not  compromised  the  safety  and/or  security  of  the  system). 

5.  Record  changes  to  configuration  items  and  the  reasons  for  the 
changes  as  appropriate. 


SG  3  Establish  Integrity 

Integrity  of  baselines  is  established  and  maintained. 

The  integrity  of  the  baselines,  established  by  processes  associated  with 
the  Establish  Baselines  specific  goal,  and  maintained  by  processes 
associated  with  the  Track  and  Control  Changes  specific  goal,  is 
provided  by  the  specific  practices  under  this  specific  goal. 

SP  3.1  Establish  Configuration  Management  Records 

Establish  and  maintain  records  describing  configuration  items. 


Typical  Acquirer  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Change  log 

3.  Status  of  configuration  items 

4.  Differences  between  baselines  [acq] 

Typical  Supplier  Deliverables 

1 .  Revision  history  of  product  and  supplier  deliverables  defined  in  the 
supplier  agreement  [acq] 

2.  Change  log  [acqj 

3.  Copy  of  the  change  requests  [acq] 

4.  Status  of  product  and  supplier  deliverables  [acq] 

5.  Differences  between  baselines  [acq] 
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Subpractices 

1 .  Record  configuration  management  actions  in  sufficient  detail  so  the 
content  and  status  of  each  configuration  item  is  known  and 
previous  versions  can  be  recovered. 

2.  Ensure  that  relevant  stakeholders  have  access  to  and  knowledge 
of  the  configuration  status  of  the  configuration  items. 

3.  Specify  the  latest  version  of  the  baselines. 

4.  Identify  the  version  of  configuration  items  that  constitute  a 
particular  baseline. 

5.  Describe  the  differences  between  successive  baselines. 

6.  Revise  the  status  and  history  (i.e.,  changes  and  other  actions)  of 
each  configuration  item  as  necessary. 

SP  3.2  Perform  Configuration  Audits 

Perform  configuration  audits  to  maintain  integrity  of  the 

configuration  baselines. 


Configuration  audits  confirm  that  the  resulting  baselines  and 
documentation  conform  to  a  specified  standard  or  requirement.  Audit 
results  should  be  recorded  as  appropriate.  (See  the  glossary  for  a 
definition  of  “configuration  audit.”) 

Typical  Acquirer  Work  Products 

1.  Configuration  audit  results 

2.  Action  items 

Typical  Supplier  Deliverables 
1 .  Supplier  configuration  audit  results  [acqj 

Subpractices 

1 .  Assess  the  integrity  of  the  baselines. 

2.  Confirm  that  the  configuration  management  records  correctly 
identify  the  configuration  items. 

3.  Review  the  structure  and  integrity  of  the  items  in  the  configuration 
management  system. 

4.  Confirm  the  completeness  and  correctness  of  the  items  in  the 
configuration  management  system. 

Completeness  and  correctness  of  the  content  is  based  on  the  requirements  as 
stated  in  the  plan  and  the  disposition  of  approved  change  requests,  [acqj 
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5.  Confirm  compliance  with  applicable  configuration  management 
standards  and  procedures. 

6.  Track  action  items  from  the  audit  to  closure. 
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DECISION  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Decision  Analysis  and  Resolution  (DAR)  is  to  analyze 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria. 


Introductory  Notes 


The  Decision  Analysis  and  Resolution  process  area  involves 
establishing  guidelines  to  determine  which  issues  should  be  subjected 
to  a  formal  evaluation  process  and  then  applying  formal  evaluation 
processes  to  these  issues. 

A  formal  evaluation  process  is  a  structured  approach  to  evaluating 
alternative  solutions  against  established  criteria  to  determine  a 
recommended  solution  to  address  an  issue.  A  formal  evaluation 
process  involves  the  following  actions: 

•  Establishing  the  criteria  for  evaluating  alternatives 

•  Identifying  alternative  solutions 

•  Selecting  methods  for  evaluating  alternatives 

•  Evaluating  the  alternative  solutions  using  the  established  criteria 
and  methods 

•  Selecting  recommended  solutions  from  the  alternatives  based  on 
the  evaluation  criteria 

Rather  than  using  the  phrase  “alternative  solutions  to  address  issues” 
each  time  it  is  needed,  we  will  use  one  of  two  shorter  phrases: 
“alternative  solutions”  or  “alternatives.” 

A  repeatable  criteria-based  decision-making  process  is  especially 
important,  both  while  making  the  critical  decisions  that  define  and  guide 
the  acquisition  process  and  later  when  critical  decisions  are  made  with 
the  selected  supplier.  The  establishment  of  a  formal  process  for 
decision-making  provides  the  acquirer  with  documentation  of  the 
decision  rationale.  Such  documentation  allows  the  criteria  for  critical 
decisions  to  be  revisited  when  changes  or  technology  insertion 
decisions  that  impact  requirements  or  other  critical  project  parameters 
are  considered  A  formal  process  also  supports  the  communication  of 
decisions  between  acquirer  and  supplier,  [acqj 
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A  formal  evaluation  process  reduces  the  subjective  nature  of  the 
decision  and  has  a  higher  probability  of  selecting  a  solution  that  meets 
the  multiple  demands  of  the  relevant  stakeholders. 

While  the  primary  application  of  this  process  area  is  for  selected 
technical  concerns,  formal  evaluation  processes  can  also  be  applied  to 
many  nontechnical  issues,  particularly  when  a  project  is  being  planned. 
Issues  that  have  multiple  alternative  solutions  and  evaluation  criteria 
lend  themselves  to  a  formal  evaluation  process. 

Guidelines  are  created  for  deciding  when  to  use  formal  evaluation 
processes  to  address  unplanned  issues.  Guidelines  often  suggest  using 
formal  evaluation  processes  when  issues  are  associated  with  medium 
to  high  risks  or  when  issues  affect  the  ability  to  achieve  project 
objectives. 

Formal  evaluation  processes  can  vary  in  formality,  type  of  criteria,  and 
methods  employed.  Less  formal  decisions  can  be  analyzed  in  a  few 
hours,  use  only  a  few  criteria  (e.g.,  effectiveness  and  cost  to 
implement),  and  result  in  a  one-  or  two-page  report.  More  formal 
decisions  may  require  separate  plans,  months  of  effort,  meetings  to 
develop  and  approve  criteria,  simulations,  prototypes,  piloting,  and 
extensive  documentation. 

Both  numeric  and  non-numeric  criteria  can  be  used  in  a  formal 
evaluation  process.  Numeric  criteria  use  weights  to  reflect  the  relative 
importance  of  the  criteria.  Non-numeric  criteria  use  a  more  subjective 
ranking  scale  (e.g.,  high,  medium,  low).  More  formal  decisions  may 
require  a  full  trade  study. 

A  formal  evaluation  process  identifies  and  evaluates  alternative 
solutions.  The  eventual  selection  of  a  solution  may  involve  iterative 
activities  of  identification  and  evaluation.  Portions  of  identified 
alternatives  may  be  combined,  emerging  technologies  may  change 
alternatives,  and  the  business  situation  of  vendors  may  change  during 
the  evaluation  period. 

A  recommended  alternative  is  accompanied  by  documentation  of  the 
selected  methods,  criteria,  alternatives,  and  rationale  for  the 
recommendation.  The  documentation  is  distributed  to  the  relevant 
stakeholders;  it  provides  a  record  of  the  formal  evaluation  process  and 
rationale  that  is  useful  to  other  projects  that  encounter  a  similar  issue. 

While  some  of  the  decisions  made  throughout  the  life  of  the  project 
involve  the  use  of  a  formal  evaluation  process,  others  do  not.  As 
mentioned  earlier,  guidelines  should  be  established  to  determine  which 
issues  should  be  subjected  to  a  formal  evaluation  process. 
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Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
general  planning  for  projects. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process.  The 
project’s  defined  process  includes  a  formal  evaluation  process  for  each 
selected  issue  and  incorporates  the  use  of  guidelines  for  applying  a 
formal  evaluation  process  to  unforeseen  issues. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  mitigating  risks.  A  formal  evaluation  process  is  often 
used  to  address  issues  with  identified  medium  or  high  risks.  Selected 
solutions  typically  affect  risk  mitigation  plans. 

Specific  Goal  and  Practice  Summary 

SG  1  Evaluate  Alternatives 

SP  1 .1  Establish  Guidelines  for  Decision  Analysis 

SP  1.2  Establish  Evaluation  Criteria 

SP  1 .3  Identify  Alternative  Solutions 

SP  1 .4  Select  Evaluation  Methods 

SP  1 .5  Evaluate  Alternatives 

SP1.6  Select  Solutions 


Specific  Practices  by  Goal 


SG  1  Evaluate  Alternatives 

Decisions  are  based  on  an  evaluation  of  alternatives  using  established 
criteria. 

Issues  requiring  a  formal  evaluation  process  may  be  identified  at  any 
time.  The  objective  should  be  to  identify  issues  as  early  as  possible  to 
maximize  the  time  available  to  resolve  them 

SP  1.1  Establish  Guidelines  for  Decision  Analysis 

Establish  and  maintain  guidelines  to  determine  which  issues 
are  subject  to  a  formal  evaluation  process. 


Not  every  decision  is  significant  enough  to  require  a  formal  evaluation 
process.  The  choice  between  the  trivial  and  the  truly  important  will  be 
unclear  without  explicit  guidance.  Whether  a  decision  is  significant  or 
not  is  dependent  on  the  project  and  circumstances,  and  is  determined 
by  the  established  guidelines. 

Typical  guidelines  for  determining  when  to  require  a  formal  evaluation 
process  include  the  following:  [acq] 
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•  When  a  decision  is  directly  related  to  topics  assessed  as  being  of 
medium  or  high  risk 

•  When  a  decision  is  related  to  changing  work  products  under 
configuration  management 

•  When  a  decision  would  cause  schedule  delays  over  a  certain 
percentage  or  specific  amount  of  time 

•  When  a  decision  affects  the  ability  to  achieve  project  objectives 

•  When  the  costs  of  the  formal  evaluation  process  are  reasonable 
when  compared  to  the  decision’s  impact 

•  When  a  legal  obligation  exists  during  a  solicitation 

•  When  there  is  a  risk  that  the  decision  will  have  a  significant  adverse 
effect  on  cost,  quality,  resources,  or  schedule 

•  When  legal  or  supplier  agreement  issues  need  to  be  resolved 

Refer  to  the  Risk  Management  process  area  for  more  information  about 

determining  which  issues  are  medium  or  high  risk. 


Examples  of  when  to  use  a  formal  evaluation  process  include  the  following:  [acq] 

•  On  decisions  to  trade  off  performance,  cost,  and  schedule  requirements  during  an 
acquisition 

•  On  selecting,  terminating,  or  renewing  suppliers 


Typical  Acquirer  Work  Products 

1 .  Guidelines  for  when  to  apply  a  formal  evaluation  process 
Subpractices 

1.  Establish  guidelines. 

2.  Incorporate  the  use  of  the  guidelines  into  the  defined  process 
where  appropriate. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

SP  1.2  Establish  Evaluation  Criteria 

Establish  and  maintain  the  criteria  for  evaluating  alternatives, 
and  the  relative  ranking  of  these  criteria. 


The  evaluation  criteria  provide  the  basis  for  evaluating  alternative 
solutions.  The  criteria  are  ranked  so  that  the  highest  ranked  criteria 
exert  the  most  influence  on  the  evaluation. 
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This  process  area  is  referenced  by  many  other  process  areas  in  the 
model,  and  there  are  many  contexts  in  which  a  formal  evaluation 
process  can  be  used.  Therefore,  in  some  situations  you  may  find  that 
criteria  have  already  been  defined  as  part  of  another  process.  This 
specific  practice  does  not  suggest  that  a  second  development  of  criteria 
be  conducted. 

Document  the  evaluation  criteria  to  minimize  the  possibility  that 
decisions  will  be  second-guessed,  or  that  the  reason  for  making  the 
decision  will  be  forgotten.  Decisions  based  on  criteria  that  are  explicitly 
defined  and  established  remove  barriers  to  stakeholder  buy-in. 

Typical  Acquirer  Work  Products 

1.  Documented  evaluation  criteria 

2.  Rankings  of  criteria  importance 
Subpractices 

1 .  Define  the  criteria  for  evaluating  alternative  solutions. 

Criteria  should  be  traceable  to  requirements,  scenarios,  business  case 
assumptions,  business  objectives,  or  other  documented  sources.  Types  of  criteria 
to  consider  include  the  following:  [acqj 

•  Technology  limitations 

•  Environmental  impact 

•  Risks 

•  Total  ownership  and  life-cycle  costs 

2.  Define  the  range  and  scale  for  ranking  the  evaluation  criteria. 

Scales  of  relative  importance  for  evaluation  criteria  can  be  established  with  non¬ 
numeric  values  or  with  formulas  that  relate  the  evaluation  parameter  to  a 
numerical  weight,  [acqj 

3.  Rank  the  criteria. 

4.  Assess  the  criteria  and  their  relative  importance. 

5.  Evolve  the  evaluation  criteria  to  improve  their  validity. 

6.  Document  the  rationale  for  the  selection  and  rejection  of  evaluation 
criteria. 

SP  1.3  Identify  Alternative  Solutions 

Identify  alternative  solutions  to  address  issues. 
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A  wider  range  of  alternatives  can  surface  by  soliciting  as  many 
stakeholders  as  practical  for  input.  Input  from  stakeholders  with  diverse 
skills  and  backgrounds  can  help  teams  identify  and  address 
assumptions,  constraints,  and  biases.  Brainstorming  sessions  may 
stimulate  innovative  alternatives  through  rapid  interaction  and  feedback. 
Sufficient  candidate  solutions  may  not  be  furnished  for  analysis.  As  the 
analysis  proceeds,  other  alternatives  should  be  added  to  the  list  of 
potential  candidate  solutions.  The  generation  and  consideration  of 
multiple  alternatives  early  in  a  decision  analysis  and  resolution  process 
increases  the  likelihood  that  an  acceptable  decision  will  be  made,  and 
that  consequences  of  the  decision  will  be  understood. 

Typical  Acquirer  Work  Products 

1.  Identified  alternatives 

Typical  Supplier  Deliverables 

1 .  Supplier  identified  alternatives,  if  any  [acq] 

Subpractices 

1.  Perform  a  literature  search. 

2.  Identify  alternatives  for  consideration  in  addition  to  those  that  may 
be  provided  with  the  issue. 

3.  Document  the  proposed  alternatives. 

SP1.4  Select  Evaluation  Methods 

Select  the  evaluation  methods. 


Methods  for  evaluating  alternative  solutions  against  established  criteria 
can  range  from  simulations  to  the  use  of  probabilistic  models  and 
decision  theory.  These  methods  need  to  be  carefully  selected.  The  level 
of  detail  of  a  method  should  be  commensurate  with  cost,  schedule, 
performance,  and  risk  impacts. 

While  many  problems  may  need  only  one  evaluation  method,  some 
problems  may  require  multiple  methods.  For  instance,  simulations  may 
augment  a  trade  study  to  determine  which  design  alternative  best 
meets  a  given  criterion. 

Suppliers  competing  to  develop  a  technical  solution  for  the  acquirer 
may  be  directly  evaluated  in  a  final  competition  that  possibly  involves 
performance  or  functional  demonstration  of  proposed  solutions,  [acqj 

Typical  Acquirer  Work  Products 

1.  Selected  evaluation  methods 


140 


Decision  Analysis  and  Resolution 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Subpractices 

1 .  Select  the  methods  based  on  the  purpose  for  analyzing  a  decision 
and  on  the  availability  of  the  information  used  to  support  the 
method. 

Typical  evaluation  methods  include  the  following:  [acqi 

•  Benchmarking  studies 

•  Cost  studies 

•  Business  opportunity  studies 

•  Surveys 

•  Extrapolations  based  on  field  experience  and  prototypes 

•  User  review  and  comment 

•  Judgment  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi  Method) 

2.  Select  evaluation  methods  based  on  their  ability  to  focus  on  the 
issues  at  hand  without  being  overly  influenced  by  side  issues. 

3.  Determine  the  measures  needed  to  support  the  evaluation  method. 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  specifying  measures,  [acq] 

SP1.5  Evaluate  Alternatives 

Evaluate  alternative  solutions  using  the  established  criteria  and 
methods. 


Evaluating  alternative  solutions  involves  analysis,  discussion,  and 
review.  Iterative  cycles  of  analysis  are  sometimes  necessary. 
Supporting  analyses,  experimentation,  prototyping,  piloting,  or 
simulations  may  be  needed  to  substantiate  scoring  and  conclusions. 

Often,  the  relative  importance  of  criteria  is  imprecise  and  the  total  effect 
on  a  solution  is  not  apparent  until  after  the  analysis  is  performed.  In 
cases  where  the  resulting  scores  differ  by  relatively  small  amounts,  the 
best  selection  among  alternative  solutions  may  not  be  clear  cut. 
Challenges  to  criteria  and  assumptions  should  be  encouraged. 

Typical  Acquirer  Work  Products 
1.  Evaluation  results 

Subpractices 

1.  Evaluate  the  proposed  alternative  solutions  using  the  established 
evaluation  criteria  and  selected  methods. 

2.  Evaluate  the  assumptions  related  to  the  evaluation  criteria  and  the 
evidence  that  supports  the  assumptions. 
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3.  Evaluate  whether  uncertainty  in  the  values  for  alternative  solutions 
affects  the  evaluation  and  address  as  appropriate. 

4.  Perform  simulations,  modeling,  prototypes,  and  pilots  as  necessary 
to  exercise  the  evaluation  criteria,  methods,  and  alternative 
solutions. 

Untested  criteria,  their  relative  importance,  and  supporting  data  or  functions  may 
cause  the  validity  of  solutions  to  be  questioned.  Criteria  and  their  relative  priorities 
and  scales  can  be  tested  with  trial  runs  against  a  set  of  alternatives.  These  trial 
runs  of  a  select  set  of  criteria  allow  for  the  evaluation  of  the  cumulative  impact  of 
the  criteria  on  a  solution.  If  the  trials  reveal  problems,  different  criteria  or 
alternatives  might  be  considered  to  avoid  biases,  [acqi 

5.  Consider  new  alternative  solutions,  criteria,  or  methods  if  the 
proposed  alternatives  do  not  test  well;  repeat  the  evaluations  until 
alternatives  do  test  well. 

Document  the  rationale  for  the  addition  of  new  alternatives  or  methods  and 
changes  to  criteria,  as  well  as  the  results  of  interim  evaluations.  Determine  the 
score(s)  for  each  alternative  based  upon  the  criteria  evaluations  and  the  scoring 
method(s)  previously  determined,  [acqi 

6.  Document  the  results  of  the  evaluation. 

SP  1.6  Select  Solutions 

Select  solutions  from  the  alternatives  based  on  the  evaluation 

criteria. 


Selecting  solutions  involves  weighing  the  results  from  the  evaluation  of 
alternatives.  Risks  associated  with  implementation  of  the  solutions  must 
be  assessed. 

Typical  Acquirer  Work  Products 

1 .  Recommended  solutions  to  address  significant  issues 
Subpractices 

1.  Assess  the  risks  associated  with  implementing  the  recommended 
solution. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks. 

2.  Document  the  results  and  rationale  for  the  recommended  solution. 
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INTEGRATED  PROJECT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Integrated  Project  Management  (IPM)  is  to  establish 
and  manage  the  project  and  the  involvement  of  the  relevant 
stakeholders  according  to  an  integrated  and  defined  process  that  is 
tailored  from  the  organization’s  set  of  standard  processes. 


Introductory  Notes 


Integrated  Project  Management  involves  the  following: 

•  Establishing  the  project’s  defined  process  by  tailoring  the 
organization’s  set  of  standard  processes 

•  Managing  the  project  using  the  project’s  defined  process 

•  Establishing  the  work  environment  for  the  project  based  on  the 
organization’s  work  environment  standards 

•  Using  and  contributing  to  the  organizational  process  assets 

•  Enabling  relevant  stakeholders’  concerns  to  be  identified, 
considered,  and,  when  appropriate,  addressed  during  the 
development  of  the  product 

•  Ensuring  that  the  relevant  stakeholders  perform  their  tasks  in  a 
coordinated  and  timely  manner  (1)  to  address  product  and  product- 
component  requirements,  plans,  objectives,  issues,  and  risks;  (2)  to 
fulfill  their  commitments;  and  (3)  to  identify,  track,  and  resolve 
issues 

The  integrated  and  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  is  called  the  project’s  defined 
process. 

Integrated  Project  Management  includes  organizational  acquisition 
guidance,  regulations,  instructions,  and  acquisition  practices 
established  to  be  used  across  various  projects,  [acq] 

Managing  the  project’s  effort,  cost,  schedule,  staffing,  risks,  and  other 
factors  is  tied  to  the  tasks  of  the  project’s  defined  process.  The 
implementation  and  management  of  the  project’s  defined  process  are 
typically  described  in  the  project  plan.  Certain  activities  may  be  covered 
in  other  plans  that  affect  the  project,  such  as  the  quality  assurance  plan, 
risk  management  strategy,  and  the  configuration  management  plan. 


Integrated  Project  Management 


143 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Since  the  defined  process  for  each  project  is  tailored  from  the 
organization’s  set  of  standard  processes,  variability  among  projects  is 
typically  reduced  and  projects  can  more  easily  share  process  assets, 
data,  and  lessons  learned. 

This  process  area  also  addresses  the  coordination  of  all  activities 
associated  with  the  project  such  as  the  following: 

•  Development  activities  (e.g.,  requirements  development,  design, 
and  verification) 

•  Service  activities  (e.g.,  delivery,  help  desk,  operations,  and 
customer  contact) 

•  Acquisition  activities  (e.g.,  solicitation,  contract  monitoring,  and 
transition  to  operation) 

•  Support  activities  (e.g.,  configuration  management,  documentation, 
marketing,  and  training. 

The  working  interfaces  and  interactions  among  relevant  stakeholders 
internal  and  external  to  the  project  are  planned  and  managed  to  ensure 
the  quality  and  integrity  of  the  entire  product.  Relevant  stakeholders 
participate,  as  appropriate,  in  defining  the  project’s  defined  process  and 
the  project  plan.  Reviews  and  exchanges  are  regularly  conducted  with 
the  relevant  stakeholders  to  ensure  that  coordination  issues  receive 
appropriate  attention  and  everyone  involved  with  the  project  is 
appropriately  aware  of  the  status,  plans,  and  activities.  (See  the 
definition  of  “relevant  stakeholder”  in  the  glossary.)  In  defining  the 
project’s  defined  process,  formal  interfaces  are  created  as  necessary  to 
ensure  that  appropriate  coordination  and  collaboration  occurs. 

The  acquirer  needs  to  involve  and  integrate  all  relevant  acquisition, 
technical,  support,  and  operational  stakeholders.  Depending  on  the 
scope  and  risk  of  the  project,  the  coordination  efforts  with  the  supplier 
can  be  significant,  [acq] 

Formal  interfaces  among  relevant  stakeholders  take  the  form  of 
memorandums  of  understanding  (MOUs),  memorandums  of 
agreements  (MOAs),  contractual  commitments,  associated  supplier 
agreements,  and  similar  documents,  depending  on  the  nature  of  the 
interfaces  and  involved  stakeholders,  [acq] 

This  process  area  applies  in  any  organizational  structure,  including 
projects  that  are  structured  as  line  organizations,  matrix  organizations, 
or  integrated  teams.  The  terminology  should  be  appropriately 
interpreted  for  the  organizational  structure  in  place. 
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Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  the  project. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  relevant  stakeholders  and  their  appropriate  involvement  in 
the  project. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and  work  environment 
standards. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  measuring  and  analyzing 
processes. 

Refer  to  Acquisition  Management  process  area  for  information  about 
managing  supplier  agreements,  [acq] 

Specific  Goal  and  Practice  Summary 

SG  1  Use  the  Project’s  Defined  Process 

SP  1 .1  Establish  the  Project’s  Defined  Process 
SP  1 .2  Use  Organizational  Process  Assets  for  Planning 
Project  Activities 

SP  1 .3  Establish  the  Project's  Work  Environment 
SP1.4  Integrate  Plans 

SP  1 .5  Manage  the  Project  Using  the  Integrated  Plans 
SP  1 .6  Contribute  to  the  Organizational  Process  Assets 
SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 
SP  2.1  Manage  Stakeholder  Involvement 

SP  2.2  Manage  Dependencies 

SP  2.3  Resolve  Coordination  Issues 

Specific  Practices  by  Goal 


SG  1 _ Use  the  Project’s  Defined  Process _ 

The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes. 

The  project’s  defined  process  must  include  those  processes  from  the 
organization’s  set  of  standard  processes  that  address  all  processes 
necessary  to  acquire  or  develop  and  maintain  the  product.  The  product- 
related  life-cycle  processes,  such  as  the  manufacturing  and  support 
processes,  are  developed  concurrently  with  the  product. 
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SP  1.1  Establish  the  Project’s  Defined  Process 

Establish  and  maintain  the  project's  defined  process. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives. 

The  project’s  defined  process  consists  of  defined  processes  that 
form  an  integrated,  coherent  life  cycle  for  the  project. 

The  project’s  defined  process  logically  sequences  acquirer  activities 
and  supplier  deliverables  (as  identified  in  the  supplier  agreement)  to 
deliver  a  product  that  meets  the  requirements,  [acq] 

The  project's  defined  process  should  satisfy  the  project's  contractual 
and  operational  needs,  opportunities,  and  constraints.  It  is  designed  to 
provide  a  best  fit  for  the  project’s  needs.  A  project's  defined  process  is 
based  on  the  following  factors: 

•  Customer  requirements 

•  Product  and  product-component  requirements 

•  Commitments 

•  Organizational  process  needs  and  objectives 

•  Operational  environment 

•  Business  environment 

The  project’s  defined  process  is  driven  by  the  acquisition  strategy.  For 
example,  whether  the  acquisition  strategy  is  to  introduce  new 
technology  to  the  organization  or  focuses  on  consolidating  acquired 
products  or  services  in  use  by  the  acquirer  impacts  the  project’s  defined 
process,  [acq] 

Typical  Acquirer  Work  Products 

1 .  The  project’s  defined  process 

Subpractices 

1 .  Select  a  life-cycle  model  from  those  available  from  the 
organizational  process  assets. 

2.  Select  the  standard  processes  from  the  organization's  set  of 
standard  processes  that  best  fit  the  needs  of  the  project. 

3.  Tailor  the  organization’s  set  of  standard  processes  and  other 
organizational  process  assets  according  to  the  tailoring  guidelines 
to  produce  the  project’s  defined  process. 
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Sometimes  the  available  life-cycle  models  and  standard  processes  are 
inadequate  to  meet  a  specific  project’s  needs.  Sometimes  the  project  will  be 
unable  to  produce  required  work  products  or  measures.  In  such  circumstances, 
the  project  will  need  to  seek  approval  to  deviate  from  what  is  required  by  the 
organization.  Waivers  are  provided  for  this  purpose,  [acqj 

4.  Use  other  artifacts  from  the  organization's  process  asset  library  as 
appropriate. 

Other  artifacts  may  include  the  following:  [acqj 

•  Lessons-learned  documents 

•  Templates 

•  Example  documents 

•  Estimating  models 

5.  Document  the  project's  defined  process. 

Examples  of  project  activities  include  the  following:  [acqi 

j  •  Proposal  evaluation 
:  •  Supplier  selection 
i  •  Development  of  supplier  agreements 
j  •  Management  of  supplier  agreements 

•  Acceptance  of  supplier  deliverables 

6.  Conduct  peer  reviews  of  the  project's  defined  process. 

7.  Revise  the  project's  defined  process  as  necessary. 

SP  1.2  Use  Organizational  Process  Assets  for  Planning  Project 
Activities 

Use  the  organizational  process  assets  and  measurement 
repository  for  estimating  and  planning  the  project’s  activities. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and  the  organization’s 
measurement  repository. 

When  available,  use  the  results  of  previous  planning  and  execution 
activities  as  predictors  of  the  relative  scope  and  risk  of  the  effort  being 
estimated  for  the  current  acquisition,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Project  estimates 

2.  Project  plans 
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Subpractices 

1 .  Base  the  activities  for  estimating  and  planning  on  the  tasks  and 
work  products  of  the  project's  defined  process. 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project's  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  is  a  basis  for  developing  a  realistic  plan,  [acqj 

2.  Use  the  organization’s  measurement  repository  in  estimating  the 
project’s  planning  parameters. 

This  estimate  typically  includes  the  following:  [acqi 

•  Using  appropriate  historical  data  from  this  project  or  similar  projects 

•  Accounting  for  and  recording  similarities  and  differences  between  the  current 
project  and  those  projects  whose  historical  data  will  be  used 

•  Independently  validating  the  historical  data 

•  Recording  the  reasoning,  assumptions,  and  rationale  used  to  select  the  historical 
data 

SP  1.3  Establish  the  Project’s  Work  Environment 

Establish  and  maintain  the  project’s  work  environment  based 
on  the  organization’s  work  environment  standards. 


An  appropriate  work  environment  for  a  project  comprises  an 
infrastructure  of  facilities,  tools,  and  equipment  that  people  need  to 
perform  their  jobs  effectively  in  support  of  business  and  project 
objectives.  The  work  environment  and  its  components  are  maintained  at 
a  level  of  performance  and  reliability  indicated  by  the  organizational 
work  environment  standards.  As  required,  the  project’s  work 
environment  or  some  of  its  components  can  be  developed  internally  or 
acquired  from  external  sources. 

The  project’s  work  environment  might  encompass  environments  for 
product  integration,  verification,  and  validation  or  they  might  be 
separate  environments. 

Refer  to  the  Establish  Work  Environment  Standards  specific  practice  in 
the  Organizational  Process  Definition  process  area  for  more  information 
on  work  environment  standards. 

Typical  Acquirer  Work  Products 

1 .  Equipment  and  tools  for  the  project 

2.  Installation,  operation,  and  maintenance  manuals  for  the  project 
work  environment 

3.  User  surveys  and  results 

4.  Usage,  performance,  and  maintenance  records 
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5.  Support  services  for  the  project’s  work  environment 
Subpractices 

1 .  Plan,  design,  and  install  a  work  environment  for  the  project. 

The  critical  aspects  of  the  project  work  environment  are,  like  any  other  product, 
requirements  driven.  Work  environment  functionality  and  operations  are  explored 
with  the  same  rigor  as  is  done  for  any  other  product  development,  [acq] 

It  is  necessary  to  make  tradeoffs  among  performance  improvements,  costs,  and 
:  risks.  The  following  are  examples  of  each:  [acqj 

i  •  Performance  improvements  may  include  timely  interoperable  communications, 
safety,  security,  and  maintainability. 

:  •  Costs  may  include  capital  outlays,  training,  support  structure,  disassembly  and 
disposal  of  existing  environments,  and  operation  and  maintenance  of  the 
environment. 

•  Risks  may  include  workflow  and  project  disruptions. 

i  Examples  of  equipment  and  tools  include  the  following:  [acqj 

|  •  Office  software 

:  •  Decision  support  software 

i  •  Project  management  tools 

|  •  Requirements  management  tools,  design  tools 

:  •  Configuration  management  tools 

i  •  Evaluation  tools 

•  Test  and/or  evaluation  equipment 

2.  Provide  ongoing  maintenance  and  operational  support  for  the 
project’s  work  environment. 

Maintenance  and  support  of  the  work  environment  can  be  accomplished  either 
with  capabilities  found  inside  the  organization  or  hired  from  outside  the 
organization,  [acqj 

Examples  of  maintenance  and  support  approaches  include  the  following:  [acq] 

:  •  Hiring  people  to  perform  the  maintenance  and  support 
i  •  Training  people  to  perform  the  maintenance  and  support 
|  •  Contracting  the  maintenance  and  support 
:  •  Developing  expert  users  for  selected  tools 

3.  Maintain  the  qualification  of  the  components  of  the  project’s  work 
environment. 
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Components  include  software,  databases,  hardware,  tools,  test  equipment,  and 
appropriate  documentation.  Qualification  of  software  includes  appropriate 
certifications.  Hardware  and  test  equipment  qualification  includes  calibration  and 
adjustment  records  and  traceability  to  calibration  standards,  [acq] 

4.  Periodically  review  how  well  the  work  environment  is  meeting  the 
project’s  needs  and  supporting  collaboration,  and  take  action  as 
appropriate. 


SP  1.4  Integrate  Plans 

Integrate  the  project  plan  and  the  other  plans  that  affect  the 
project  to  describe  the  project’s  defined  process. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  a  project  plan. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and,  in  particular,  the 
organization’s  measurement  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures  and  measurement  activities  and 
using  analytic  techniques. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives. 

This  specific  practice  extends  the  specific  practices  for  establishing  and 
maintaining  a  project  plan  to  address  additional  planning  activities  such 
as  incorporating  the  project’s  defined  process,  coordinating  with 
relevant  stakeholders,  using  organizational  process  assets, 
incorporating  plans  for  peer  reviews,  and  establishing  objective  entry 
and  exit  criteria  for  tasks. 

The  development  of  the  project  plan  should  account  for  current  and 
projected  needs,  objectives,  and  requirements  of  the  organization, 
customer,  suppliers,  and  end  users,  as  appropriate. 

Typical  Acquirer  Work  Products 

1.  Integrated  plans 

Typical  Supplier  Deliverables 

1.  Supplier  plans  [acq] 

Subpractices 

1 .  Integrate  other  plans  that  affect  the  project  with  the  project  plan. 
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Other  plans  that  affect  the  project  may  include  the  following:  [acqi 

•  Quality  assurance  plans 

•  Configuration  management  plans 

•  Risk  management  strategy 

•  Documentation  plans 

2.  Incorporate  into  the  project  plan  the  definitions  of  measures  and 
measurement  activities  for  managing  the  project. 

3.  Identify  and  analyze  product  and  project  interface  risks. 

4.  Schedule  the  tasks  in  a  sequence  that  accounts  for  critical 
development  factors  and  project  risks. 


Examples  of  factors  considered  in  scheduling  include  the  following:  [acqj 

j  •  Size  and  complexity  of  the  tasks 
:  •  Needs  of  the  customer  and  end  users 
i  •  Availability  of  critical  resources 
:  •  Availability  of  key  personnel 

5.  Incorporate  the  plans  for  performing  peer  reviews  on  the  work 
products  of  the  project's  defined  process. 

6.  Incorporate  the  training  needed  to  perform  the  project’s  defined 
process  in  the  project’s  training  plans. 

7.  Establish  objective  entry  and  exit  criteria  to  authorize  the  initiation 
and  completion  of  the  tasks  described  in  the  work  breakdown 
structure  (WBS). 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  the  WBS. 

8.  Ensure  that  the  project  plan  is  appropriately  compatible  with  the 
plans  of  relevant  stakeholders. 

9.  Identify  how  conflicts  will  be  resolved  that  arise  among  relevant 
stakeholders. 

Refer  to  the  Acquisition  Management  process  area  for  more 
information  about  resolving  issues  related  to  supplier  agreements. 

[ACQ] 


SP  1.5  Manage  the  Project  Using  the  Integrated  Plans 

Manage  the  project  using  the  project  plan,  the  other  plans  that 
affect  the  project,  and  the  project’s  defined  process. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives  and 
coordinating  process-improvement  activities  with  the  rest  of  the 
organization. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
managing  risks. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project. 

Typical  Acquirer  Work  Products 

1 .  Work  products  created  by  performing  the  project’s  defined  process 

2.  Collected  measures  ("actuals")  and  progress  records  or  reports 

3.  Revised  requirements,  plans,  and  commitments 

4.  Integrated  plans 

Typical  Supplier  Deliverables 

1.  Supplier  progress  reports  and  performance  measures  [acq] 
Subpractices 

1 .  Implement  the  project’s  defined  process  using  the  organization's 
process  asset  library. 

This  task  typically  includes  the  following:  [acqj 

•  Incorporating  artifacts  from  the  organization’s  process  asset  library  into  the  project 
as  appropriate 

•  Using  lessons  learned  from  the  organization’s  process  asset  library  to  manage  the 
project 

2.  Monitor  and  control  the  project’s  activities  and  work  products  using 
the  project’s  defined  process,  project  plan,  and  other  plans  that 
affect  the  project. 

This  task  typically  includes  the  following:  [acqi 

•  Using  the  defined  entry  and  exit  criteria  to  authorize  the  initiation  and  determine 
the  completion  of  the  tasks 

•  Monitoring  the  activities  that  could  significantly  affect  the  actual  values  of  the 
project’s  planning  parameters 

•  Tracking  the  project’s  planning  parameters  using  measurable  thresholds  that  will 
trigger  investigation  and  appropriate  actions 

•  Monitoring  product  and  project  interface  risks 
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•  Managing  external  and  internal  commitments  based  on  the  plans  for  the  tasks  and 
work  products  of  implementing  the  project’s  defined  process 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project’s  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  along  with  well-defined  control  mechanisms  achieves  better  visibility 
into  the  project’s  performance  and  better  control  of  the  project,  [acqi 

3.  Obtain  and  analyze  the  selected  measures  to  manage  the  project 
and  support  the  organization’s  needs. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  obtaining  and  analyzing 
measures. 

4.  Periodically  review  and  align  the  project’s  performance  with  the 
current  and  anticipated  needs,  objectives,  and  requirements  of  the 
organization,  customer,  and  end  users,  as  appropriate. 

This  review  includes  alignment  with  the  organizational  process  needs  and 
objectives,  [acqj 


Examples  of  actions  that  achieve  alignment  include  the  following:  [acqi 

•  Accelerating  the  schedule,  with  appropriate  adjustments  to  other  planning 
parameters  and  the  project  risks 

•  Changing  the  requirements  in  response  to  a  change  in  market  opportunities  or 
customer  and  end-user  needs 

•  Terminating  the  project 


SP  1.6  Contribute  to  the  Organizational  Process  Assets 

Contribute  work  products,  measures,  and  documented 
experiences  to  the  organizational  process  assets. 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process  improvement  proposals. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  the  organization’s 
measurement  repository,  and  the  organization’s  process  asset  library. 

This  specific  practice  addresses  collecting  information  from  processes 
in  the  project’s  defined  process. 

Typical  Acquirer  Work  Products 

1 .  Proposed  improvements  to  the  organizational  process  assets 

2.  Actual  process  and  product  measures  collected  from  the  project 
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3.  Documentation  (e.g.,  exemplary  process  descriptions,  plans, 
training  modules,  checklists,  and  lessons  learned) 

Subpractices 

1 .  Propose  improvements  to  the  organizational  process  assets. 

2.  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  recording  planning  and  replanning  data. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  recording  measures. 

3.  Submit  documentation  for  possible  inclusion  in  the  organization's 
process  asset  library. 

4.  Document  lessons  learned  from  the  project  for  inclusion  in  the 
organization's  process  asset  library. 


SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 

Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  is 
conducted. 


SP  2.1  Manage  Stakeholder  Involvement 

Manage  the  involvement  of  the  relevant  stakeholders  in  the 
project. 


Stakeholder  involvement  is  managed  according  to  the  project’s 
integrated  and  defined  process. 

The  acquirer  encourages  stakeholder  involvement  and  ensures  that 
stakeholder  coordination  and  cooperation  are  maximized  to  the  extent 
possible.  The  supplier  agreement  provides  the  basis  for  managing 
supplier  involvement  in  the  project,  [acq] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  about 
establishing  and  maintaining  commitments. 

Typical  Acquirer  Work  Products 

1 .  Agendas  and  schedules  for  collaborative  activities 

2.  Documented  issues  [acq] 

3.  Recommendations  for  resolving  relevant  stakeholder  issues 
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Typical  Supplier  Deliverables 

1.  Documented  issues  (e.g.,  issues  with  customer  requirements, 
product  and  product-component  requirements,  product 
architecture,  and  product  design)  [acq] 

Subpractices 

1.  Coordinate  with  the  relevant  stakeholders  who  should  participate  in 
the  project’s  activities. 

2.  Ensure  that  work  products  that  are  produced  to  satisfy 
commitments  meet  the  requirements  of  the  recipient  projects. 

3.  Develop  recommendations  and  coordinate  the  actions  to  resolve 
misunderstandings  and  problems  with  the  product  and  product- 
component  requirements,  product  and  product-component 
architecture,  and  product  and  product-component  design. 


SP  2.2  Manage  Dependencies 

Participate  with  relevant  stakeholders  to  identify,  negotiate,  and 
track  critical  dependencies. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  about 
establishing  and  maintaining  commitments. 


Typical  Acquirer  Work  Products 

1 .  Defects,  issues,  and  action  items  resulting  from  reviews  with 
relevant  stakeholders 

2.  Critical  dependencies 

3.  Commitments  to  address  critical  dependencies 

4.  Status  of  critical  dependencies 

Typical  Supplier  Deliverables 

1 .  Status  of  critical  dependencies  as  documented  in  the  supplier 
agreement  [acq] 


Subpractices 

1 .  Conduct  reviews  with  relevant  stakeholders. 

2.  Identify  each  critical  dependency. 

3.  Establish  need  dates  and  plan  dates  for  each  critical  dependency 
based  on  the  project  schedule. 


4. 


Integrated  Project  Management 


Review  and  get  agreement  on  the  commitments  to  address  each 
critical  dependency  with  the  people  responsible  for  providing  the 
work  product  and  the  people  receiving  the  work  product. 
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5.  Document  the  critical  dependencies  and  commitments. 

The  acquirer  documents  the  supplier  commitments  to  meet  critical  dependencies 
in  the  supplier  agreement,  [acqj 

6.  Track  the  critical  dependencies  and  commitments  and  take 
corrective  action  as  appropriate. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  commitments. 

Tracking  the  critical  dependencies  typically  includes  the  following:  [acqi 

•  Evaluating  the  effects  of  late  and  early  completion  for  impacts  on  future  activities 
and  milestones 

•  Resolving  actual  and  potential  problems  with  the  responsible  parties  whenever 
possible 

•  Escalating  to  the  appropriate  party  the  actual  and  potential  problems  not 
resolvable  by  the  responsible  individual  or  group 

SP  2.3  Resolve  Coordination  Issues 

Resolve  issues  with  relevant  stakeholders. 

Examples  of  coordination  issues  include  the  following:  [acqi 

i  •  Late  critical  dependencies  and  commitments 

:  •  Product-level  problems 

i  •  Unavailability  of  critical  resources  or  personnel 
i  •  Incomplete  customer  requirements 
•  Unresolved  defects 


Typical  Acquirer  Work  Products 

1 .  Relevant  stakeholder  coordination  issues 

2.  Status  of  relevant  stakeholder  coordination  issues 
Subpractices 

1 .  Identify  and  document  issues. 

2.  Communicate  issues  to  the  relevant  stakeholders. 

3.  Resolve  issues  with  the  relevant  stakeholders. 

4.  Escalate  to  the  appropriate  managers  those  issues  not  resolvable 
with  the  relevant  stakeholders. 

5.  Track  the  issues  to  closure. 
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6.  Communicate  with  the  relevant  stakeholders  on  the  status  and 
resolution  of  the  issues. 
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MEASUREMENT  AND  ANALYSIS 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Measurement  and  Analysis  (MA)  is  to  develop  and 
sustain  a  measurement  capability  that  is  used  to  support  management 
information  needs. 


Introductory  Notes 


The  Measurement  and  Analysis  process  area  involves  the  following: 

•  Specifying  the  objectives  of  measurement  and  analysis  such  that 
they  are  aligned  with  identified  information  needs  and  objectives 

•  Specifying  the  measures,  data  collection  and  storage  mechanisms, 
analysis  techniques,  and  reporting  and  feedback  mechanisms 

•  Implementing  the  collection,  storage,  analysis,  and  reporting  of  the 
data 

•  Providing  objective  results  that  can  be  used  in  making  informed 
decisions,  and  taking  appropriate  corrective  actions 

The  integration  of  measurement  and  analysis  activities  into  the 
processes  of  the  project  supports  the  following: 

•  Objective  planning  and  estimating 

•  Tracking  actual  performance  against  established  plans  and 
objectives 

•  Identifying  and  resolving  process-related  issues 

•  Providing  a  basis  for  incorporating  measurement  into  additional 
processes  in  the  future 

The  staff  required  to  implement  a  measurement  capability  may  or  may 
not  be  employed  in  a  separate  organization-wide  program. 
Measurement  capability  may  be  integrated  into  individual  projects  or 
other  organizational  functions  (e.g.,  quality  assurance). 

The  initial  focus  for  measurement  activities  is  at  the  project  level. 
However,  a  measurement  capability  may  prove  useful  for  addressing 
organization-  and/or  enterprise-wide  information  needs.  To  support  this 
capability,  the  measurement  activities  should  support  information  needs 
at  multiple  levels  including  the  business,  organizational  unit,  and  project 
to  minimize  re-work  as  the  organization  matures. 
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Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 
repository. 

Measurement  and  analysis  of  the  product  components  provided  by 
suppliers  is  essential  for  effective  management  of  the  quality  and  costs 
of  the  project.  It  is  possible,  with  careful  management  of  supplier 
agreements,  to  provide  insight  into  the  data  that  support  supplier- 
performance  analysis. 

The  measures  specified  by  the  acquirer  are  designed  to  enable  the 
acquirer  to  determine  the  status  of  its  progress  and  output,  the 
supplier’s  progress  and  output  per  contractual  requirements,  and  the 
status  of  the  evolving  products  acquired.  An  acquirer  establishes 
measurement  objectives  for  acquirer  activities,  work  products  and  for 
supplier  deliverables.  The  measurement  objectives  are  derived  from 
information  needs  that  come  from  project  objectives,  organizational 
objectives  and  business  needs.  The  measurement  objectives  are  used 
to  define  specific  measures  and  collection,  analysis,  storage  and  usage 
procedures  for  the  measures.  These  measures  are  specified  in  the 
project  plan  and  for  the  supplier  in  the  supplier  agreement,  [acqj 

In  projects  where  multiple  products  are  acquired  to  deliver  a  capability 
to  the  end  user,  or  where  there  are  relationships  with  other  projects  to 
acquire  joint  capabilities,  additional  measures  may  be  identified  to  track 
and  achieve  interoperability  objectives  in  terms  of  programmatic, 
technical,  and  operational  interfaces,  [acq] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  performance  information  needs. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  managing  measurement  work  products. 

Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  meeting  customer  requirements  and  related 
information  needs,  [acqj 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs. 
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Refer  to  Solicitation  and  Supplier  Agreement  Development  including 
supplier  measures  in  the  solicitation  package  and  in  the  supplier 
agreement,  [acq] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement 
repository. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  understanding  variation  and  the  appropriate  use  of 
statistical  analysis  techniques. 

Specific  Goal  and  Practice  Summary 

SG  1  Align  Measurement  and  Analysis  Activities 

SP  1.1  Establish  Measurement  Objectives 

SP  1 .2  Specify  Measures 

SP  1 .3  Specify  Data  Collection  and  Storage  Procedures 
SP  1 .4  Specify  Analysis  Procedures 
SG  2  Provide  Measurement  Results 

SP2.1  Collect  Measurement  Data 
SP  2.2  Analyze  Measurement  Data 
SP  2.3  Store  Data  and  Results 
SP  2.4  Communicate  Results 


Specific  Practices  by  Goal 


SG  1  Align  Measurement  and  Analysis  Activities 

Measurement  objectives  and  activities  are  aligned  with  identified 
information  needs  and  objectives. 

The  specific  practices  covered  under  this  specific  goal  may  be 
addressed  concurrently  or  in  any  order: 

•  When  establishing  measurement  objectives,  experts  often  think 
ahead  about  necessary  criteria  for  specifying  measures  and 
analysis  procedures.  They  also  think  concurrently  about  the 
constraints  imposed  by  data  collection  and  storage  procedures. 

•  It  often  is  important  to  specify  the  essential  analyses  that  will  be 
conducted  before  attending  to  details  of  measurement  specification, 
data  collection,  or  storage. 

SP  1.1  Establish  Measurement  Objectives 

Establish  and  maintain  measurement  objectives  that  are 
derived  from  identified  information  needs  and  objectives. 


Measurement  objectives  document  the  purposes  for  which 
measurement  and  analysis  are  done,  and  specify  the  kinds  of  actions 
that  may  be  taken  based  on  the  results  of  data  analyses. 
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Measurement  objectives  focus  on  the  acquirer’s  performance  as  well  as 
the  supplier’s  performance,  and  on  understanding  their  impacts  on 
customer  operational  and  financial  performance.  Measurement 
objectives  for  the  supplier  enable  defining  and  tracking  service  level 
expectations  documented  in  the  supplier  agreement,  [acqj 

Identify  what  information  is  needed  to  [acq] 

•  maintain  alignment  to  project  objectives  and  provide  results  that 
keep  a  project  on  track  to  its  successful  conclusion 

•  support  the  organizational  unit’s  ability  to  establish  an  infrastructure 
that  reinforces  and  grows  the  acquirer’s  capabilities  of  processes, 
people,  and  technologies,  as  appropriate 

•  support  the  enterprise’s  ability  to  monitor  and  manage  their  financial 
results  and  their  customer  expectations,  as  appropriate 

The  sources  for  measurement  objectives  may  be  management, 
technical,  project,  product,  or  process  implementation  needs. 

The  measurement  objectives  may  be  constrained  by  existing 
processes,  available  resources,  or  other  measurement  considerations. 
Judgments  may  need  to  be  made  about  whether  the  value  of  the  results 
will  be  commensurate  with  the  resources  devoted  to  doing  the  work. 

Modifications  to  identified  information  needs  and  objectives  may,  in 
turn,  be  indicated  as  a  consequence  of  the  process  and  results  of 
measurement  and  analysis. 

An  acquirer  needs  to  consider  the  impact  of  existing  supplier 
agreements  on  measurement  objectives,  [acq] 

Sources  of  information  needs  and  objectives  may  include  the  following: 

•  Project  plans 

•  Monitoring  of  project  performance 

•  Interviews  with  managers  and  others  who  have  information  needs 

•  Established  management  objectives 

•  Strategic  plans 

•  Business  plans 

•  Formal  requirements  or  contractual  obligations 

•  Recurring  or  other  troublesome  management  or  technical  problems 

•  Experiences  of  other  projects  or  organizational  entities 

•  External  industry  benchmarks 

•  Process-improvement  plans 
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•  Supplier  agreements  and  contractual  requirements  (e.g.,  service 
levels)  [acq] 

Example  measurement  objectives  include  the  following: 

•  Reduce  time  to  delivery 

•  Reduce  total  life  cycle  cost 

•  Deliver  specified  functionality  completely 

•  Improve  prior  levels  of  quality 

•  Improve  prior  customer  satisfaction  ratings 

•  Maintain  and  improve  the  acquirer/supplier  relationships 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  project  performance  information  needs. 

Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  meeting  customer  requirements  and  related 
information  needs,  [acqj 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs. 

Typical  Acquirer  Work  Products 

1 .  Measurement  objectives 

Subpractices 

1 .  Document  information  needs  and  objectives. 

2.  Prioritize  information  needs  and  objectives. 

3.  Document,  review,  and  update  measurement  objectives. 

It  is  important  to  carefully  consider  the  purposes  and  intended  uses  of 
measurement  and  analysis,  [acq] 

The  measurement  objectives  are  documented,  reviewed  by  management  and 
other  relevant  stakeholders,  and  updated  as  necessary.  Doing  so  enables 
traceability  to  subsequent  measurement  and  analysis  activities,  and  helps  ensure 
that  the  analyses  will  properly  address  identified  information  needs  and 
objectives,  [acq] 

4.  Provide  feedback  for  refining  and  clarifying  information  needs  and 
objectives  as  necessary. 
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Identified  information  needs  and  objectives  may  need  to  be  refined  and  clarified 
as  a  result  of  setting  measurement  objectives.  Initial  descriptions  of  information 
needs  may  be  unclear  or  ambiguous.  Conflicts  may  arise  between  existing  needs 
and  objectives.  Precise  targets  on  an  already  existing  measure  may  be 
unrealistic,  [acqi 

5.  Review  appropriate  measurement  objectives  with  potential 
suppliers  throughout  the  solicitation,  obtaining  their  feedback,  and 
commitment,  [acq] 

6.  Maintain  traceability  of  the  measurement  objectives  to  the  identified 
information  needs  and  objectives. 

Of  course,  the  measurement  objectives  may  also  change  to  reflect  evolving 
information  needs  and  objectives,  [acqi 


SP  1.2  Specify  Measures 

Specify  measures  to  address  the  measurement  objectives. 


Measurement  objectives  are  refined  into  precise,  quantifiable 
measures. 

Measurement  of  project  and  organizational  work  can  typically  be  traced 
to  one  or  more  of  measurement  information  categories.  These 
categories  include  the  following:  schedule  and  progress,  effort  and  cost, 
size  and  stability,  and  quality,  [acq] 

Measures  may  be  either  “base”  or  “derived.”  Data  for  base  measures 
are  obtained  by  direct  measurement.  Data  for  derived  measures  come 
from  other  data,  typically  by  combining  two  or  more  base  measures. 

Derived  measures  typically  are  expressed  as  ratios,  composite  indices, 
or  other  aggregate  summary  measures.  They  are  often  more 
quantitatively  reliable  and  meaningfully  interpretable  than  the  base 
measures  used  to  generate  them. 

There  is  a  direct  relationship  between  measurement  objectives, 
measurement  categories,  base  measures,  and  derived  measures.  This 
direct  relationship  is  depicted  in  Table  5.3:  [acqj 

Table  5.3:  Measurement  Relationships  [acqi 


Example 

Measurement 

Objectives 

Measurement 

Information 

Categories 

Example  Base  Measures 

Example  Derived  Measures 

Shorter  time  to 
delivery 

Schedule  and 
Progress 

Estimated  and  Actual  Start 
and  End  Dates  by  Task 

Estimated  and  Actual  Start 

Schedule  Performance  Index 

Percentage  of  Project  on  Time 
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Example 

Measurement 

Objectives 

Measurement 

Information 

Categories 

Example  Base  Measures 

Example  Derived  Measures 

and  End  Dates  of  Acquisition 
Tasks 

Schedule  Estimation  Accuracy 

Reduced  total  life 
cycle  cost 

Effort  and  Cost 

Estimated  and  Actual  Effort 
Hours 

Estimated  and  Actual  Cost 

Return  on  Investment 

Cost  Performance  Index 

Deliver  specified 

functionality 

completely 

Size  and  Stability 

Function  Points  Count 

Lines  of  Code  Count 

Requirements  Count 

Requirements  Volatility 

Size  Estimation  Accuracy 

Amount  of  New,  Modified  and 
Reused  Code 

Percentage  of  Function  Points 
Completed 

Improve  levels  of 
quality 

Quality 

Product  Defects  Count 

Customer  Satisfaction 
Survey  Scores 

Supplier  Performance  and 
Relationship  Scores 

Defect  Removal  Efficiency 

Number  of  Defects  Per  Phase 

Total  Unresolved  Defects 

Customer  Satisfaction  Trends 

Supplier  Performance  and 
Relationship  Trends 
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To  manage  projects,  an  acquirer  uses  supplier  data  (base  measures) 
and  supplier  reported  derived  measures  in  addition  to  measures  of 
acquirer  progress  and  output.  The  supplier  measures  required  by  the 
acquirer  allow  the  acquirer  to  comprehensively  address  the 
measurement  objectives  and  to  comprehensively  determine  the 
progress  of  the  project.  In  some  cases,  these  supplier  measures  will 
augment  the  acquirer’s  measures  (e.g.,  supplier’s  schedule 
performance  index  and  size  estimation  accuracy).  In  most  cases,  the 
supplier  measures  will  be  the  primary  source  of  data,  especially  with 
regard  to  the  development  of  the  acquired  product  or  service.  For 
instance,  measurement  and  analysis  of  the  product  or  product 
components  provided  by  a  supplier  through  technical  performance 
measures  is  essential  for  effective  management  of  the  quality,  size, 
cost,  and  schedule  of  the  project  (e.g.,  amount  of  new,  modified,  reused 
code,  percentage  of  function  points  complete,  and  defect  removal 
efficiency).  These  supplier  measures  must  be  defined  in  the  supplier 
agreement  including  a  supplier’s  measurement  collection  requirements 
and  the  measurement  reports  to  be  provided  to  the  acquirer,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Specifications  of  base  and  derived  measures 

2.  Acceptance  criteria  for  supplier  measures  [acq] 

Subpractices 

1.  Identify  candidate  measures  based  on  documented  measurement 
objectives. 

The  measurement  objectives  are  refined  into  specific  measures.  The  identified 
candidate  measures  are  categorized  and  specified  by  name  and  unit  of  measure. 

[ACQ] 

2.  Identify  existing  measures  that  already  address  the  measurement 
objectives. 

Specifications  for  measures  may  already  exist,  perhaps  established  for  other 
purposes  earlier  or  elsewhere  in  the  organization,  [acqi 

3.  Specify  operational  definitions  for  the  measures. 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows:  [acqj 

•  Communication:  What  has  been  measured,  how  was  it  measured,  what  are  the 
units  of  measure,  and  what  has  been  included  or  excluded? 

•  Repeatability:  Can  the  measurement  be  repeated,  given  the  same  definition,  to 
get  the  same  results? 

4.  Specify  acceptance  criteria  based  on  operational  definitions  for  the 
measures  that  will  come  from  suppliers  to  the  acquirer  in  a  way 
that  enables  their  intended  use.  [acq] 
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Measures  may  be  provided  by  the  supplier  as  detailed  measurement  data  or 
measurement  reports.  The  measures  that  come  from  suppliers  must  be 
associated  with  the  acquirer’s  acceptance  criteria  for  supplier  measures.  The 
acceptance  criteria  may  be  captured  in  measurement  specifications  or  by 
checklists,  if  appropriate,  [acqj 

The  acceptance  criteria  should  be  defined  in  away  that  enables  the  intended  use 
of  the  supplier  measures,  such  as  potential  aggregation  and  analysis.  They  need 
to  include  any  criteria  associated  with  the  collection  and  transfer  mechanisms  and 
procedures  that  must  be  performed  by  the  supplier.  Consider  all  characteristics 
about  the  supplier  measures  that  may  impact  their  use  such  as  differences  in 
financial  calendars  used  by  different  suppliers,  [acqi 

5.  Prioritize,  review,  and  update  measures. 

Proposed  specifications  of  the  measures  are  reviewed  for  their  appropriateness 
with  potential  end  users  and  other  relevant  stakeholders.  Priorities  are  set  or 
changed,  and  specifications  of  the  measures  are  updated  as  necessary,  [acqi 


SP  1.3  Specify  Data  Collection  and  Storage  Procedures 

Specify  how  measurement  data  will  be  obtained  and  stored. 


Explicit  specification  of  collection  methods  helps  ensure  that  the  right 
data  are  collected  properly.  It  may  also  aid  in  further  clarifying 
information  needs  and  measurement  objectives. 

Proper  attention  to  storage  and  retrieval  procedures  helps  ensure  that 
data  are  available  and  accessible  for  future  use. 

The  supplier  agreement  specifies  what  measurement  data  the  supplier 
has  to  provide  to  the  acquirer,  in  what  format  it  has  to  be  provided  to  the 
acquirer,  how  the  measurement  data  will  be  collected  and  stored  by  the 
supplier  (e.g.,  retention  period  of  data),  how  and  how  often  it  will  be 
transferred  to  the  acquirer  and  who  has  access  to  the  data.  Some 
supplier  data  may  be  considered  proprietary  by  the  supplier  and  may 
need  to  be  protected  as  such  by  the  acquirer.  Also  consider  that  some 
of  the  acquirer  measurement  data  (e.g.,  total  project  cost  data)  may  be 
proprietary  and  should  not  be  shared  with  suppliers.  An  acquirer  needs 
to  plan  for  the  collection,  storage,  and  access  control  of  this  type  of 
sensitive  data,  [acqj 

The  acquirer  must  ensure  that  appropriate  mechanisms  are  in  place  to 
obtain  the  measurement  data  from  the  supplier  in  a  consistent  way.  It  is 
critical  for  the  acquirer  to  insist  in  the  supplier  agreement  on  accurate 
data  collection  by  the  supplier  for  the  acquirer’s  measurement  and 
analysis,  [acqi 

Typical  Acquirer  Work  Products 

1.  Data  collection  and  storage  procedures 
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2.  Data  collection  tools 

Typical  Supplier  Deliverables 

1 .  Recommendations  for  data  collection  and  storage  procedures  [acqj 
Subpractices 

1 .  Identify  existing  sources  of  data  that  are  generated  from  current 
work  products,  processes,  or  transactions. 

2.  Identify  measures  for  which  data  are  needed,  but  are  not  currently 
available. 

3.  Specify  how  to  collect  and  store  the  data  for  each  required 
measure. 

Explicit  specifications  are  made  of  how,  where,  and  when  the  data  will  be 
collected.  Procedures  for  collecting  valid  data  are  specified.  The  data  are  stored  in 
an  accessible  manner  for  analysis,  and  it  is  determined  whether  they  will  be  saved 
for  possible  reanalysis  or  documentation  purposes,  [acqi 

Questions  to  be  considered  typically  include  the  following:  [acqj 

•  Have  the  frequency  of  collection  and  the  points  in  the  process  where 
measurements  will  be  made  been  determined? 

•  Has  the  time  line  that  is  required  to  move  measurement  results  from  the  points  of 
collection  to  repositories,  other  databases,  or  end  users  been  established? 

•  Who  is  responsible  for  obtaining  the  data? 

•  Who  is  responsible  for  data  storage,  retrieval,  and  security? 

•  Have  necessary  supporting  tools  been  developed  or  acquired? 

•  Have  required  data  collection  requirements  and  applicable  procedures  been 
specified  in  supplier  agreement  standards  and  related  documents? 

4.  Create  data  collection  mechanisms  and  process  guidance. 

Data  collection  and  storage  mechanisms  are  well  integrated  with  other  normal 
work  processes.  Data  collection  mechanisms  may  include  manual  or  automated 
forms  and  templates.  Clear,  concise  guidance  on  correct  procedures  is  available 
to  those  responsible  for  doing  the  work.  Training  is  provided  as  necessary  to 
clarify  the  processes  necessary  for  collection  of  complete  and  accurate  data  and 
to  minimize  the  burden  on  those  who  must  provide  and  record  the  data,  [acqj 

Create  mechanisms  to  transfer  data  from  the  supplier  to  the  acquirer,  along  with 
process  guidance,  as  appropriate.  Data  collection  from  a  supplier  may  be 
integrated  with  periodic  monitoring  and  review  of  supplier  activities.  Applicable 
standard  report  formats  and/or  tools  to  be  used  for  reporting  by  the  supplier  must 
be  specified  in  the  supplier  agreement,  iacqi 

5.  Support  automatic  collection  of  the  data  where  appropriate  and 
feasible. 
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6.  Prioritize,  review,  and  update  data  collection  and  storage 
procedures. 

Proposed  procedures  are  reviewed  for  their  appropriateness  and  feasibility  with 
those  who  are  responsible  for  providing,  collecting,  and  storing  the  data.  They 
also  may  have  useful  insights  about  how  to  improve  existing  processes,  or  be 
able  to  suggest  other  useful  measures  or  analyses,  [acqj 

Review  data  collection  and  storage  procedures  with  potential  suppliers  throughout 
the  solicitation.  Update  data  collection  and  storage  procedures  as  appropriate, 
and  obtain  supplier  commitment  to  collect  and  store  measurement  data  and 
reference  the  procedures  in  the  supplier  agreement,  [acqi 

7.  Update  measures  and  measurement  objectives  as  necessary. 


SP  1.4  Specify  Analysis  Procedures 

Specify  how  measurement  data  will  be  analyzed  and  reported. 


Specifying  the  analysis  procedures  in  advance  ensures  that  appropriate 
analyses  will  be  conducted  and  reported  to  address  the  documented 
measurement  objectives  (and  thereby  the  information  needs  and 
objectives  on  which  they  are  based).  This  approach  also  provides  a 
check  that  the  necessary  data  will  in  fact  be  collected. 

The  supplier  agreement  defines  the  required  data  analysis  and  the 
definition  and  examples  of  the  measures  the  supplier  must  provide  to 
the  acquirer,  [acq] 

Typical  Acquirer  Work  Products 

1.  Analysis  specification  and  procedures 

2.  Data  analysis  tools 

Typical  Supplier  Deliverables 

1 .  Recommendations  for  analysis  specification  and  procedures  [acq] 
Subpractices 

1 .  Specify  and  prioritize  the  analyses  that  will  be  conducted  and  the 
reports  that  will  be  prepared. 

Early  attention  should  be  paid  to  the  analyses  that  will  be  conducted  and  to  the 
manner  in  which  the  results  will  be  reported.  These  should  meet  the  following 
criteria:  [acqi 

•  The  analyses  explicitly  address  the  documented  measurement  objectives 

•  Presentation  of  the  results  is  clearly  understandable  by  the  audiences  to  whom 
the  results  are  addressed 

Priorities  may  have  to  be  set  within  available  resources,  [acqi 
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Establish  and  maintain  a  description  of  the  analysis  approach  for  data  element(s) 
and  a  description  of  the  reports  that  must  be  provided  by  the  supplier;  provide  a 
reference  to  the  analysis  specifications  and  procedures  in  the  supplier  agreement. 

[ACQ] 

2.  Select  appropriate  data  analysis  methods  and  tools. 

Refer  to  the  Select  Measures  and  Analytic  Techniques  and  Apply 
Statistical  Methods  to  Understand  Variation  specific  practices  of 
the  Quantitative  Project  Management  process  area  for  more 
information  about  the  appropriate  use  of  statistical  analysis 
techniques  and  understanding  variation,  respectively. 

Issues  to  be  considered  typically  include  the  following:  [acqj 

•  Choice  of  visual  display  and  other  presentation  techniques  (e.g.,  pie  charts,  bar 
charts,  histograms,  radar  charts,  line  graphs,  scatter  plots,  or  tables) 

•  Choice  of  appropriate  descriptive  statistics  (e.g.,  arithmetic  mean,  median,  or 
mode) 

•  Decisions  about  statistical  sampling  criteria  when  it  is  impossible  or  unnecessary 
to  examine  every  data  element 

•  Decisions  about  how  to  handle  analysis  in  the  presence  of  missing  data  elements 

•  Selection  of  appropriate  analysis  tools 

Descriptive  statistics  are  typically  used  in  data  analysis  to  do  the  following:  [acqi 

•  Examine  distributions  on  the  specified  measures  (e.g.,  central  tendency,  extent  of 
variation,  data  points  exhibiting  unusual  variation) 

•  Examine  the  interrelationships  among  the  specified  measures  (e.g.,  comparisons 
of  defects  by  phase  of  the  product’s  life  cycle  or  by  product  component) 

•  Display  changes  over  time 

3.  Specify  administrative  procedures  for  analyzing  the  data  and 
communicating  the  results. 

Issues  to  be  considered  typically  include  the  following:  [acqj 

•  Identifying  the  persons  and  groups  responsible  for  analyzing  the  data  and 
presenting  the  results 

•  Determining  the  time  line  to  analyze  the  data  and  present  the  results 

•  Determining  the  venues  for  communicating  the  results  (e.g.,  progress  reports, 
transmittal  memos,  written  reports,  or  staff  meetings) 

Data  collected  from  a  supplier  is  subjected  to  validity  checks  that  can  be  achieved 
by  means  of  periodic  audits  of  the  supplier’s  execution  of  the  data  collection  and 
analysis  procedures  for  acquirer  required  measures.  The  acquirer’s  option  to 
perform  validity  checks  of  the  measurement  data  collected  by  the  supplier  and  the 
supplier’s  execution  of  their  required  analysis  procedures  must  be  defined  in  the 
supplier  agreement,  [acqj 
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4.  Review  and  update  the  proposed  content  and  format  of  the 
specified  analyses  and  reports. 

All  of  the  proposed  content  and  format  are  subject  to  review  and  revision, 
including  analytic  methods  and  tools,  administrative  procedures,  and  priorities. 

The  relevant  stakeholders  consulted  should  include  intended  end  users, 
sponsors,  data  analysts,  and  data  providers,  [acqi 

Review  the  specified  analyses  and  reports  with  suppliers  and  identify  their 
commitment  to  support  the  analysis,  and  review  any  recommendations  they  may 
provide  related  to  analysis  of  measurement  data,  [acqj 

5.  Update  measures  and  measurement  objectives  as  necessary. 

Just  as  measurement  needs  drive  data  analysis,  clarification  of  analysis  criteria 
can  affect  measurement.  Specifications  for  some  measures  may  be  refined  further 
based  on  the  specifications  established  for  data  analysis  procedures.  Other 
measures  may  prove  to  be  unnecessary,  or  a  need  for  additional  measures  may 
be  recognized,  [acq] 

The  exercise  of  specifying  how  measures  will  be  analyzed  and  reported  may  also 
suggest  the  need  for  refining  the  measurement  objectives  themselves,  [acqj 

6.  Specify  criteria  for  evaluating  the  utility  of  the  analysis  results  and 
the  conduct  of  the  measurement  and  analysis  activities. 

Criteria  for  evaluating  the  utility  of  the  analysis  might  address  the  extent  to  which 
the  following  apply:  [acqj 

•  The  results  are  (1)  provided  on  a  timely  basis,  (2)  understandable,  and  (3)  used 
for  decision  making. 

•  The  work  does  not  cost  more  to  perform  than  is  justified  by  the  benefits  that  it 
provides. 

Criteria  for  evaluating  the  conduct  of  the  measurement  and  analysis  might  include 
the  extent  to  which  the  following  apply:  [acqj 

•  The  amount  of  missing  data  or  the  number  of  flagged  inconsistencies  is  beyond 
specified  thresholds. 

•  There  is  selection  bias  in  sampling  (e.g.,  only  satisfied  end  users  are  surveyed  to 
evaluate  end-user  satisfaction,  or  only  unsuccessful  projects  are  evaluated  to 
determine  overall  productivity). 

•  The  measurement  data  are  repeatable  (e.g.,  statistically  reliable). 

•  Statistical  assumptions  have  been  satisfied  (e.g.,  about  the  distribution  of  data  or 
about  appropriate  measurement  scales). 
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SG  2  Provide  Measurement  Results 

Measurement  results  that  address  identified  information  needs  and 
objectives  are  provided. 

The  primary  reason  for  doing  measurement  and  analysis  is  to  address 
identified  information  needs  and  objectives.  Measurement  results  based 
on  objective  evidence  can  help  to  monitor  performance,  fulfill 
contractual  obligations,  make  informed  management  and  technical 
decisions,  and  enable  corrective  actions  to  be  taken. 


SP  2.1  Collect  Measurement  Data 

Obtain  specified  measurement  data. 


The  data  necessary  for  analysis  are  obtained  and  checked  for 
completeness  and  integrity. 

The  supplier’s  measurement  data  is  collected  according  to  the  data 
collection  and  storage  procedures  as  defined  in  the  supplier 
agreements.  The  data  necessary  for  analysis  are  obtained  and  checked 
for  completeness  and  integrity,  [acqj 


Typical  Acquirer  Work  Products 

1 .  Base  and  derived  measurement  data  sets 

2.  Results  of  data  integrity  tests 

Typical  Supplier  Deliverables 

1 .  Base  and  derived  supplier  measurement  data  sets  [acq] 

2.  Results  of  data  integrity  tests  of  supplier  measurement  data  [acq] 


Subpractices 

1 .  Obtain  the  data  for  base  measures. 

Data  are  collected  as  necessary  for  previously  used  as  well  as  for  newly  specified 
base  measures.  Existing  data  are  gathered  from  project  records  or  from 
elsewhere  in  the  organization,  [acq] 

Data  is  obtained  from  the  supplier  for  base  measures  as  defined  in  the  supplier 
agreement,  [acq] 

2.  Generate  the  data  for  derived  measures. 


Values  are  newly  calculated  for  all  derived  measures,  [acqi 


Derived  measures  are  obtained  from  the  supplier  as  defined  in  the  supplier 
agreement,  [acqi 


3. 
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All  measurements  are  subject  to  error  in  specifying  or  recording  data.  It  is  always 
better  to  identify  such  errors  and  to  identify  sources  of  missing  data  early  in  the 
measurement  and  analysis  cycle,  [acqi 

Checks  can  include  scans  for  missing  data,  out-of-bounds  data  values,  and 
unusual  patterns  and  correlation  across  measures.  It  is  particularly  important  to  do 
the  following:  [acq] 

•  Test  and  correct  for  inconsistency  of  classifications  made  by  human  judgment 
(i.e.,  to  determine  how  frequently  people  make  differing  classification  decisions 
based  on  the  same  information,  otherwise  known  as  “inter-coder  reliability”). 

•  Empirically  examine  the  relationships  among  the  measures  that  are  used  to 
calculate  additional  derived  measures.  Doing  so  can  ensure  that  important 
distinctions  are  not  overlooked  and  that  the  derived  measures  convey  their 
intended  meanings  (otherwise  known  as  “criterion  validity”). 

Use  acceptance  criteria  to  verify  the  results  of  data  integrity  tests  conducted  by 
the  supplier  and  of  the  integrity  of  supplier  data.  Follow  up  with  suppliers  if  data  is 
not  available  or  data  integrity  checks  indicate  potential  errors  in  data,  [acqi 

Refer  to  the  Acquisition  Management  process  area  for  information 
about  resolving  supplier  agreement  issues,  [acqj 


SP  2.2  Analyze  Measurement  Data 

Analyze  and  interpret  measurement  data. 


The  measurement  data  are  analyzed  as  planned,  additional  analyses 
are  conducted  as  necessary,  results  are  reviewed  with  relevant 
stakeholders,  and  necessary  revisions  for  future  analyses  are  noted. 

Typical  Acquirer  Work  Products 
1.  Analysis  results  and  draft  reports 

Typical  Supplier  Deliverables 

1 .  Response  to  analysis  results  and  draft  reports  [acq] 

Subpractices 

1 .  Conduct  initial  analyses,  interpret  the  results,  and  draw  preliminary 
conclusions. 

The  results  of  data  analyses  are  rarely  self-evident.  Criteria  for  interpreting  the 
results  and  drawing  conclusions  should  be  stated  explicitly,  [acqi 

Discuss  results  and  preliminary  conclusions  with  suppliers,  as  appropriate,  [acq] 

2.  Conduct  additional  measurement  and  analysis  as  necessary,  and 
prepare  results  for  presentation. 
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The  results  of  planned  analyses  may  suggest  (or  require)  additional,  unanticipated 
analyses.  In  addition,  they  may  identify  needs  to  refine  existing  measures,  to 
calculate  additional  derived  measures,  or  even  to  collect  data  for  additional  base 
measures  to  properly  complete  the  planned  analysis.  Similarly,  preparing  the 
initial  results  for  presentation  may  identify  the  need  for  additional,  unanticipated 
analyses,  [acq] 


Coordinate  additional  analyses  with  suppliers,  as  appropriate,  [acq] 

3.  Review  the  initial  results  with  relevant  stakeholders. 

It  may  be  appropriate  to  review  initial  interpretations  of  the  results  and  the  way  in 
which  they  are  presented  before  disseminating  and  communicating  them  more 
widely,  [acq] 

Relevant  stakeholders  with  whom  reviews  may  be  conducted  include  intended 
end  users  and  sponsors,  as  well  as  data  analysts  and  data  providers,  [acqj 

Review  the  initial  results  related  to  supplier  progress  or  output  also  with  suppliers 
and  determine  if  revisions  are  appropriate  based  upon  their  response,  [acqi 

4.  Refine  criteria  for  future  analyses. 

Valuable  lessons  that  can  improve  future  efforts  are  often  learned  from  conducting 
data  analyses  and  preparing  results.  Similarly,  ways  to  improve  measurement 
specifications  and  data  collection  procedures  may  become  apparent,  as  may 
ideas  for  refining  identified  information  needs  and  objectives,  [acqi 

Update  data  acceptance  criteria  for  supplier  measures,  as  appropriate,  [acqi 


SP  2.3  Store  Data  and  Results 

Manage  and  store  measurement  data,  measurement 
specifications,  and  analysis  results. 


Storing  measurement-related  information  enables  the  timely  and  cost- 
effective  future  use  of  historical  data  and  results.  The  information  also  is 
needed  to  provide  sufficient  context  for  interpretation  of  the  data, 
measurement  criteria,  and  analysis  results. 

Information  stored  typically  includes  the  following:  [acq] 

•  Measurement  plans 

•  Specifications  of  measures 

•  Sets  of  data  that  have  been  collected 

•  Analysis  reports  and  presentations 

•  Retention  period  for  data  stored 

•  Data  acceptance  criteria  for  supplier  data 


Measurement  and  Analysis 


173 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


The  stored  information  contains  or  references  the  information  needed  to 
understand  and  interpret  the  measures  and  to  assess  them  for 
reasonableness  and  applicability  (e.g.,  measurement  specifications 
used  on  different  projects  when  comparing  across  projects). 

Data  sets  for  derived  measures  typically  can  be  recalculated  and  need 
not  be  stored.  However,  it  may  be  appropriate  to  store  summaries 
based  on  derived  measures  (e.g.,  charts,  tables  of  results,  or  report 
prose). 

Interim  analysis  results  need  not  be  stored  separately  if  they  can  be 
efficiently  reconstructed. 

Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 
repository. 

Refer  to  the  Establish  the  Organization’s  Measurement  Repository 
specific  practice  of  the  Organizational  Process  Definition  process  area 
for  more  information  about  establishing  the  organization’s  measurement 
repository. 

Refer  to  the  Configuration  Management  process  area  for  information 
about  managing  measurement  work  products. 

Typical  Acquirer  Work  Products 

1 .  Stored  data  inventory 

Subpractices 

1 .  Review  the  data  to  ensure  their  completeness,  integrity,  accuracy, 
and  currency. 

2.  Store  the  data  according  to  the  data  storage  procedures. 

3.  Make  the  stored  contents  available  for  use  only  by  appropriate 
groups  and  personnel. 

The  acquirer  also  protects  measurement  data  provided  by  the  supplier  according 
to  the  supplier  agreement.  The  supplier  agreement  might  specify  that  the  acquirer 
must  restrict  access  of  a  supplier’s  measurement  data  to  employees  of  the 
acquirer  only,  [acq] 

4.  Prevent  the  stored  information  from  being  used  inappropriately. 


174 


Measurement  and  Analysis 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Examples  of  inappropriate  use  include  the  following:  [acqj 

•  Disclosure  of  information  that  was  provided  in  confidence 

•  Faulty  interpretations  based  on  incomplete,  out-of-context,  or  otherwise 
misleading  information 

•  Measures  used  to  improperly  evaluate  the  performance  of  people  or  to  rank 
projects 

•  Impugning  the  integrity  of  specific  individuals 


SP  2.4  Communicate  Results 

Report  results  of  measurement  and  analysis  activities  to  all 
relevant  stakeholders. 


The  results  of  the  measurement  and  analysis  process  are 
communicated  to  relevant  stakeholders  in  a  timely  and  usable  fashion 
to  support  decision  making  and  assist  in  taking  corrective  action. 

Relevant  stakeholders  include  intended  users,  sponsors,  data  analysts, 
and  data  providers.  Relevant  stakeholders  also  include  suppliers,  [acq] 

Typical  Acquirer  Work  Products 

1.  Delivered  reports  and  related  analysis  results 

2.  Contextual  information  or  guidance  to  aid  in  the  interpretation  of 
analysis  results 

Subpractices 

1 .  Keep  relevant  stakeholders  apprised  of  measurement  results  on  a 
timely  basis. 

To  the  extent  possible  and  as  part  of  the  normal  way  they  do  business,  users  of 
measurement  results  are  kept  personally  involved  in  setting  objectives  and 
deciding  on  plans  of  action  for  measurement  and  analysis.  The  users  are  regularly 
kept  apprised  of  progress  and  interim  results,  [acq] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  the  use  of  measurement  results. 

2.  Assist  relevant  stakeholders  in  understanding  the  results. 

Results  are  reported  in  a  clear  and  concise  manner  appropriate  to  the 
methodological  sophistication  of  the  relevant  stakeholders.  They  are 
understandable,  easily  interpretable,  and  clearly  tied  to  identified  information 
needs  and  objectives,  [acq] 

The  acquirer  establishes  and  maintains  a  standard  format  for  communicating 
measurement  data  to  suppliers,  [acq] 


Measurement  and  Analysis 


175 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


The  data  are  often  not  self-evident  to  practitioners  who  are  not  measurement 
experts.  Measurement  choices  should  be  explicitly  clear  about  the  following:  [acqi 

•  How  and  why  the  base  and  derived  measures  were  specified 

•  How  the  data  were  obtained 

•  How  to  interpret  the  results  based  on  the  data  analysis  methods  that  were  used 

•  How  the  results  address  information  needs 

Examples  of  actions  to  assist  in  understanding  of  results  include  the  following:  [acqi 

i  •  Discussing  the  results  with  the  relevant  stakeholders 
|  •  Providing  a  transmittal  memo  that  provides  background  and  explanation 
|  •  Briefing  users  on  the  results 

:  •  Providing  training  on  the  appropriate  use  and  understanding  of  measurement 
results 
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ORGANIZATIONAL  INNOVATION  AND  DEPLOYMENT 

A  Process  Management  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Organizational  Innovation  and  Deployment  (OID)  is  to 
select  and  deploy  incremental  and  innovative  improvements  that 
measurably  improve  the  organization’s  processes  and  technologies. 
The  improvements  support  the  organization’s  quality  and  process- 
performance  objectives  as  derived  from  the  organization’s  business 
objectives. 


Introductory  Notes 


The  Organizational  Innovation  and  Deployment  process  area  enables 
the  selection  and  deployment  of  improvements  that  can  enhance  the 
organization’s  ability  to  meet  its  quality  and  process-performance 
objectives.  (See  the  definition  of  “quality  and  process-performance 
objectives”  in  the  glossary.)  The  term  “improvement,”  as  used  in  this 
process  area,  refers  to  all  of  the  ideas  (proven  and  unproven)  that 
would  change  the  organization’s  processes  and  technologies  to  better 
meet  the  organization’s  quality  and  process-performance  objectives. 

Quality  and  process-performance  objectives  that  this  process  area 
might  address  include  the  following: 

•  Improved  product  quality  (e.g.,  functionality,  performance) 

•  Increased  productivity 

•  Decreased  cycle  time 

•  Greater  customer  and  end-user  satisfaction 

•  Shorter  development  or  production  time  to  change  functionality  or, 
add  new  features,  or  adapt  to  new  technologies 

•  Reduce  delivery  time 

•  Reduce  time  to  adapt  to  new  technologies  and  business  needs 
Acquirer’s  improvement  objectives  may  include  the  following:  [acq] 

•  Improved  performance  of  supply-chain  involving  multiple  suppliers 

•  Improved  inter-supplier  performance 

•  Improved  utilization  of  resources  across  the  organization 
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Achievement  of  these  objectives  depends  on  the  successful 
establishment  of  an  infrastructure  that  enables  and  encourages  all 
people  in  the  organization  to  propose  potential  improvements  to  the 
organization’s  processes  and  technologies.  Achievement  of  these 
objectives  also  depends  on  being  able  to  effectively  evaluate  and 
deploy  proposed  improvements  to  the  organization’s  processes  and 
technologies.  All  members  of  the  organization  can  participate  in  the 
organization’s  process-  and  technology-improvement  activities.  Their 
proposals  are  systematically  gathered  and  addressed. 

Improvements  may  be  identified  and  executed  by  the  acquirer  or  the 
supplier.  The  acquirer  encourages  all  suppliers  to  participate  in  the 
acquirer’s  process  and  technology  improvement  activities.  Some  of  the 
selected  improvements  may  be  deployed  across  acquirer  and  supplier 
organizations,  [acq] 

The  acquirer  and  suppliers  may  share  the  costs  and  benefits  of 
improvements.  Acquirers  may  increase  the  incentive  for  suppliers  to 
participate  in  improvement  efforts  across  the  supply  chain  by  allowing 
suppliers  to  appropriate  all  the  value  derived  from  a  contributed 
improvement  in  the  short  term  (e.g.,  6  to  18  months).  Over  time  the 
supplier  may  be  expected  to  share  a  proportion  of  those  savings  with 
the  acquirer  (e.g.,  through  cost  reductions  to  the  acquirer),  [acq] 

Pilots  are  conducted  to  evaluate  significant  changes  involving  untried, 
high-risk,  or  innovative  improvements  before  they  are  broadly  deployed. 

Process  and  technology  improvements  that  will  be  deployed  across  the 
organization  are  selected  from  process-  and  technology-improvement 
proposals  based  on  the  following  criteria: 

•  A  quantitative  understanding  of  the  organization’s  current  quality 
and  process  performance 

•  The  organization’s  quality  and  process-performance  objectives 

•  Estimates  of  the  improvement  in  quality  and  process  performance 
resulting  from  deploying  the  process  and  technology  improvements 

•  Estimated  costs  of  deploying  process  and  technology 
improvements,  and  the  resources  and  funding  available  for  such 
deployment 

The  expected  benefits  added  by  the  process  and  technology 
improvements  are  weighed  against  the  cost  and  impact  to  the 
organization.  Change  and  stability  must  be  balanced  carefully.  Change 
that  is  too  great  or  too  rapid  can  overwhelm  the  organization,  destroying 
its  investment  in  organizational  learning  represented  by  organizational 
process  assets.  Rigid  stability  can  result  in  stagnation,  allowing  the 
changing  business  environment  to  erode  the  organization’s  business 
position. 
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Improvements  are  deployed,  as  appropriate,  to  new  and  ongoing 
projects. 

In  this  process  area,  the  term  “process  and  technology  improvements” 
refers  to  incremental  and  innovative  improvements  to  processes  and 
also  to  process  or  product  technologies  (including  project  work 
environments). 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  the  assumption  is  not  met. 

The  specific  practices  in  this  process  area  complement  and  extend 
those  found  in  the  Organizational  Process  Focus  process  area.  The 
focus  of  this  process  area  is  process  improvement  that  is  based  on  a 
quantitative  knowledge  of  the  organization’s  set  of  standard  processes 
and  technologies  and  their  expected  quality  and  performance  in 
predictable  situations.  In  the  Organizational  Process  Focus  process 
area,  no  assumptions  are  made  about  the  quantitative  basis  of 
improvement. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  incorporating  the  deployed  process  improvements 
into  organizational  process  assets. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  soliciting,  collecting,  and  handling  process 
improvement  proposals  and  coordinating  the  deployment  of  process 
improvement  into  the  project’s  defined  processes. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  providing  updated  training  to  support  deployment  of  process  and 
technology  improvements. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance  objectives  and 
process  performance  models.  Quality  and  process-performance 
objectives  are  used  to  analyze  and  select  process-  and  technology- 
improvement  proposals  for  deployment.  Process  performance  models 
are  used  to  quantify  the  impact  and  benefits  of  innovations. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 
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Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  coordinating  the  deployment  of  process  and 
technology  improvements  into  the  project’s  defined  process  and  project 
work  environment. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluations  related  to  improvement  proposals 
and  innovations. 

Specific  Goal  and  Practice  Summary 

SG  1  Select  Improvements 

SP  1.1  Collect  and  Analyze  Improvement  Proposals 
SP  1 .2  Identify  and  Analyze  Innovations 

SP  1.3  Pilot  Improvements 

SP  1 .4  Select  Improvements  for  Deployment 

SG  2  Deploy  Improvements 

SP  2.1  Plan  the  Deployment 

SP  2.2  Manage  the  Deployment 

SP  2.3  Measure  Improvement  Effects 


Specific  Practices  by  Goal 


SG  1  Select  Improvements 

Process  and  technology  improvements  that  contribute  to  meeting  quality 
and  process-performance  objectives  are  selected. 


SP  1.1  Collect  and  Analyze  Improvement  Proposals 

Collect  and  analyze  process-  and  technology-improvement 
proposals. 


Each  process-  and  technology-improvement  proposal  must  be 
analyzed. 

The  acquirer  must  continuously  improve  its  processes  and  its  alignment 
with  its  suppliers.  The  acquirer  may  look  for  opportunities  to  maximize 
throughput  based  on  the  identification  of  the  most  limiting  resource  and, 
as  a  result,  create  a  more  agile  supply  chain  (e.g.,  improvement 
proposals  that  promote  a  supply  chain  that  responds  both  quickly  and 
cost  effectively),  [acqi 

Simple  process  and  technology  improvements,  with  well-understood 
benefits  and  effects,  will  not  usually  undergo  detailed  evaluations. 


Examples  of  simple  process  and  technology  improvements  include  the  following:  [acqi 

•  Combine  the  technical  review  and  management  review  for  suppliers  into  a  single 
technical/management  review. 

•  Establish  guidelines  for  multi-supplier  interactions 
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Typical  Acquirer  Work  Products 

1 .  Analyzed  process-  and  technology-improvement  proposals 

Typical  Supplier  Deliverables 

1 .  Process-  and  technology-improvement  proposals  [acq] 

Subpractices 

1 .  Collect  process-  and  technology-improvement  proposals. 

A  process-  and  technology-improvement  proposal  documents  proposed 
incremental  and  innovative  improvements  to  specific  processes  and  technologies. 
Managers  and  staff  in  the  organization,  as  well  as  customers,  end  users,  and 
suppliers  can  submit  process-  and  technology-improvement  proposals.  Process 
and  technology  improvements  may  be  implemented  at  the  local  level  before  being 
proposed  for  the  organization,  [acq] 


Examples  of  sources  for  process-  and  technology-improvement  proposals  include 

the  following:  [acq] 

•  Findings  and  recommendations  from  process  appraisals 

•  The  organization’s  quality  and  process-performance  objectives 

•  Analysis  of  data  about  customer  and  end-user  problems  as  well  as  customer  and 
end-user  satisfaction 

•  Analysis  of  data  about  project  performance  compared  to  quality  and  productivity 
objectives 

•  Analysis  of  technical  performance  measures 

•  Results  of  process  and  product  benchmarking  efforts 

•  Analysis  of  data  on  defect  causes 

•  Measured  effectiveness  of  process  activities 

•  Measured  effectiveness  of  the  project’s  work  environment 

•  Examples  of  process-  and  technology-improvement  proposals  that  were 
successfully  adopted  elsewhere 

•  Feedback  on  previously  submitted  process-  and  technology-improvement 
proposals 

•  Spontaneous  ideas  from  managers  and  staff 

•  Findings  and  recommendations  from  joint  acquirer  and  supplier  study  groups 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process-  and  technology-improvement 
proposals. 

2.  Analyze  the  costs  and  benefits  of  process-  and  technology- 
improvement  proposals  as  appropriate. 
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Process-  and  technology-improvement  proposals  that  have  a  large  cost-to-benefit 
ratio  are  rejected,  [acqj 

Criteria  for  evaluating  costs  and  benefits  include  the  following:  [acqi 

•  Contribution  toward  meeting  the  organization’s  quality  and  process-performance 
objectives 

•  Effect  on  mitigating  identified  project  and  organizational  risks 

•  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations, 
and  the  business  environment 

•  Effect  on  related  processes  and  associated  assets 

•  Cost  of  defining  and  collecting  data  that  supports  the  measurement  and  analysis 
of  the  process-  and  technology-improvement  proposal 

•  Expected  life  span  of  the  proposal 

Process-  and  technology-improvement  proposals  that  would  not  improve  the 
organization's  processes  are  rejected,  [acqj 

Process  performance  models  provide  insight  into  the  effect  of  process  changes  on 
process  capability  and  performance,  [acqi 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

3.  Identify  the  process-  and  technology-improvement  proposals  that 
are  innovative. 

Innovative  improvements  are  also  identified  and  analyzed  in  the  Identify  and 
Analyze  Innovations  specific  practice,  [acqi 

Whereas  this  specific  practice  analyzes  proposals  that  have  been  passively 
collected,  the  purpose  of  the  Identify  and  Analyze  Innovations  specific  practice  is 
to  actively  search  for  and  locate  innovative  improvements.  The  search  primarily 
involves  looking  outside  the  organization,  [acqi 

Innovative  improvements  are  typically  identified  by  reviewing  process-  and 
technology-improvement  proposals  or  by  actively  investigating  and  monitoring 
innovations  that  are  in  use  in  other  organizations  or  are  documented  in  research 
literature.  Innovation  may  be  inspired  by  internal  improvement  objectives  or  by  the 
external  business  environment,  iacqi 

Innovative  improvements  are  typically  major  changes  to  the  process  that 
represent  a  break  from  the  old  way  of  doing  things  (e.g.,  changing  the  life-cycle 
model).  Innovative  improvements  may  also  include  changes  in  the  products  that 
support,  enhance,  or  automate  the  process  (e.g.,  using  off-the-shelf  products  to 
support  the  process),  [acqj 
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Examples  of  innovative  improvements  include  the  following:  [acqj 
i  •  New  support  tools 

i  •  New  techniques,  methodologies,  processes,  or  life-cycle  models 
|  •  New  interface  standards 
:  •  New  reusable  components 
:  •  New  management  techniques 
I  •  New  quality-improvement  techniques 

•  New  process-development  and  deployment-support  tools 

4.  Identify  potential  barriers  and  risks  to  deploying  each  process-  and 
technology-improvement  proposal. 

■  Examples  of  barriers  to  deploying  process  and  technology  improvements  include 
:  the  following:  [acq] 

|  •  Turf  guarding  and  parochial  perspectives 
:  •  Unclear  or  weak  business  rationale 
i  •  Lack  of  short-term  benefits  and  visible  successes 
i  •  Unclear  picture  of  what  is  expected  from  everyone 
;•  Too  many  changes  at  the  same  time 
:  •  Lack  of  involvement  and  support  of  relevant  stakeholders 

Examples  of  risk  factors  that  affect  the  deployment  of  process  and  technology 
j  improvements  include  the  following:  [acqj 

:  •  Compatibility  of  the  improvement  with  existing  processes,  values,  and  skills  of 
potential  end  users 

i  •  Complexity  of  the  improvement 

|  •  Difficulty  implementing  the  improvement 

i  •  Ability  to  demonstrate  the  value  of  the  improvement  before  widespread 
i  deployment 

:  •  Justification  for  large,  up-front  investments  in  areas  such  as  tools  and  training 

;  •  Inability  to  overcome  "technology  drag"  where  the  current  implementation  is  used 
successfully  by  a  large  and  mature  installed  base  of  end  users 

|  •  Additional  cost  to  the  supplier 

•  Misalignment  of  acquirer  and  supplier  improvement  priorities 

5.  Estimate  the  cost,  effort,  and  schedule  required  for  deploying  each 
process-  and  technology-improvement  proposal. 

6.  Select  the  process-  and  technology-improvement  proposals  to  be 
piloted  before  broadscale  deployment. 
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Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted,  [acq] 

7.  Document  the  results  of  the  evaluation  of  each  process-  and 
technology-improvement  proposal. 

8.  Monitor  the  status  of  each  process-  and  technology-improvement 
proposal. 


SP  1.2  Identify  and  Analyze  Innovations 

Identify  and  analyze  innovative  improvements  that  could 
increase  the  organization’s  quality  and  process  performance. 


The  specific  practice,  Collect  and  Analyze  Improvement  Proposals, 
analyzes  proposals  that  are  passively  collected.  The  purpose  of  this 
specific  practice  is  to  actively  search  for,  locate,  and  analyze  innovative 
improvements.  This  search  primarily  involves  looking  outside  the 
organization. 

An  acquirer’s  customers  and  suppliers  are  vital  sources  of  innovative 
ideas.  Inter-organizational  and  organizational  learning  are  therefore 
critical  to  actively  identifying  and  analyzing  innovations,  jacq] 

Typical  Acquirer  Work  Products 

1.  Candidate  innovative  improvements 

2.  Analysis  of  proposed  innovative  improvements 

Typical  Supplier  Deliverables 

1.  Candidate  innovative  improvements  [acq] 

Subpractices 

1 .  Analyze  the  organization's  set  of  standard  processes  to  determine 
areas  where  innovative  improvements  would  be  most  helpful. 

These  analyses  are  performed  to  determine  which  subprocesses  are  critical  to 
achieving  the  organization’s  quality  and  process-performance  objectives  and 
which  ones  are  good  candidates  to  be  improved,  [acqi 

2.  Investigate  innovative  improvements  that  may  improve  the 
organization's  set  of  standard  processes. 

Investigating  innovative  improvements  involves  the  following:  [acqi 

•  Systematically  maintaining  awareness  of  leading  relevant  technical  work  and 
technology  trends 

•  Periodically  searching  for  commercially  available  innovative  improvements 

•  Collecting  proposals  for  innovative  improvements  from  the  projects  and  the 
organization 
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•  Systematically  reviewing  processes  and  technologies  used  externally  and 
comparing  them  to  those  used  within  the  organization 

•  Identifying  areas  where  innovative  improvements  have  been  used  successfully, 
and  reviewing  data  and  documentation  of  experience  using  these  improvements 

•  Identifying  improvements  that  integrate  new  technology  into  products  and  the 
project’s  work  environment 

•  Determining  where  suppliers’  products  stand  in  terms  of  technology  cycles  and 
product  life  cycles 

•  Monitoring  economies  all  over  the  world  to  spot  new  supply  bases  and  markets 

3.  Analyze  potential  innovative  improvements  to  understand  their 
effects  on  process  elements  and  predict  their  influence  on  the 
process. 

The  acquirer  together  with  its  suppliers  may  establish  an  innovation  review 
program.  This  program  may  create  time-boxed  innovation  solicitation,  which  is  a 
well-communicated  formal  process  for  analysis  and  guaranteed  response  to 
innovative  ideas  proposed  by  customers,  employees,  and  suppliers,  [acqi 

Process  performance  models  can  provide  a  basis  for  analyzing  possible  effects  of 
changes  to  process  elements,  [acqi 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

4.  Analyze  the  costs  and  benefits  of  potential  innovative 
improvements. 

Innovative  improvements  that  have  a  very  large  cost-to-benefit  ratio  are  rejected. 

[ACQ] 

5.  Create  process-  and  technology-improvement  proposals  for  those 
innovative  improvements  that  would  result  in  improving  the 
organization's  processes  or  technologies. 

6.  Select  the  innovative  improvements  to  be  piloted  before  broadscale 
deployment. 

Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted,  [acqi 

7.  Document  the  results  of  the  evaluations  of  innovative 
improvements. 


SP  1.3  Pilot  Improvements 

Pilot  process  and  technology  improvements  to  select  which 
ones  to  implement. 


Pilots  are  performed  to  assess  new  and  unproven  major  changes 
before  they  are  broadly  deployed,  as  appropriate. 
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The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects). 

Typical  Acquirer  Work  Products 

1 .  Pilot  evaluation  reports 

2.  Documented  lessons  learned  from  pilots 

Typical  Supplier  Deliverables 

1 .  Pilot  evaluation  reports  for  pilots  executed  in  supplier  environment 

[ACQ] 

2.  Documented  lessons  learned  from  pilots  executed  in  supplier 
environment  [acq] 

Subpractices 

1.  Plan  the  pilots. 

When  planning  pilots,  it  is  critical  to  define  quantitative  criteria  to  be  used  for 
evaluating  pilot  results,  [acqi 

2.  Review  and  get  relevant  stakeholder  agreement  on  the  plans  for 
the  pilots. 

3.  Consult  with  and  assist  the  people  performing  the  pilots. 

4.  Perform  each  pilot  in  an  environment  that  is  characteristic  of  the 
environment  present  in  a  broadscale  deployment. 

5.  Track  the  pilots  against  their  plans. 

6.  Review  and  document  the  results  of  pilots. 

Pilot  results  are  evaluated  using  the  quantitative  criteria  defined  during  pilot 
planning.  Reviewing  and  documenting  the  results  of  pilots  usually  involves  the 
following:  [acq] 

•  Deciding  whether  to  terminate  the  pilot,  replan  and  continue  the  pilot,  or  proceed 
with  deploying  the  process  and  technology  improvement 

•  Updating  the  disposition  of  process-  and  technology-improvement  proposals 
associated  with  the  pilot 

•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals  as  appropriate 

•  Identifying  and  documenting  lessons  learned  and  problems  encountered  during 
the  pilot 
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SP  1.4  Select  Improvements  for  Deployment 

Select  process  and  technology  improvements  for  deployment 
across  the  organization. 


Selection  of  process  and  technology  improvements  for  deployment 
across  the  organization  is  based  on  quantifiable  criteria  derived  from 
the  organization’s  quality  and  process-performance  objectives. 

Typical  Acquirer  Work  Products 

1 .  Process  and  technology  improvements  selected  for  deployment 
Subpractices 

1 .  Prioritize  the  candidate  process  and  technology  improvements  for 
deployment. 

Priority  is  based  on  an  evaluation  of  the  estimated  cost-to-benefit  ratio  with  regard 
to  the  quality  and  process-performance  objectives,  [acqi 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance 
objectives. 

2.  Select  the  process  and  technology  improvements  to  be  deployed. 

The  selection  of  the  process  improvements  is  based  on  their  priorities  and  the 
available  resources,  [acqi 

3.  Determine  how  each  process  and  technology  improvement  will  be 
deployed. 

:  Examples  of  how  the  process  and  technology  improvements  may  be  deployed 
:  include  incorporating  these  improvements  into  the  following:  [acqi 

|  •  Organizational  process  assets 
i  •  Project-specific  or  common  work  environments 
:  •  All  or  a  subset  of  the  organization’s  product  families 

i  •  All  or  a  subset  of  the  organization’s  projects 

! 

:  •  All  or  a  subset  of  the  organizational  groups 

4.  Document  the  results  of  the  selection  process. 

The  results  of  the  selection  process  usually  include  the  following:  [acqi 

•  The  selection  criteria  for  candidate  improvements 

•  The  disposition  of  each  improvement  proposal 

•  The  rationale  for  the  disposition  of  each  improvement  proposal 

•  The  assets  to  be  changed  for  each  selected  improvement 


Organizational  Innovation  and  Deployment 


187 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


SG  2  Deploy  Improvements 

Measurable  improvements  to  the  organization's  processes  and 
technologies  are  continually  and  systematically  deployed. 


SP  2.1  Plan  the  Deployment 

Establish  and  maintain  the  plans  for  deploying  the  selected 
process  and  technology  improvements. 


The  plans  for  deploying  each  process  and  technology  improvement 
may  be  included  in  the  organization’s  plan  for  organizational  innovation 
and  deployment  or  they  may  be  documented  separately. 

An  acquirer’s  plan  for  deploying  improvements  may  include  openly 
sharing  most  process  know-how  with  its  suppliers.  Any  process  related 
knowledge  that  the  acquirer  or  one  of  its  suppliers  possesses  is  viewed 
as  accessible  to  virtually  any  other  supplier  in  the  acquirer’s  supply 
chain  (perhaps  with  the  exception  of  a  direct  competitor).  In  this  case, 
the  acquirer  needs  to  establish  rules  and  norms  that  prevent  suppliers 
from  accessing  the  acquirer’s  knowledge  unless  they  first  explicitly 
agree  to  openly  share  knowledge  with  other  suppliers  of  the  acquirer. 
For  example,  the  acquirer  has  the  ability  to  impose  economic  sanctions 
(e.g.,  withdrawal  of  business)  on  the  supplier  that  violates  the  rule,  [acq] 

The  implementation  of  this  specific  practice  complements  the  Deploy 
Organizational  Process  Assets  specific  practice  in  the  Organizational 
Process  Focus  process  area,  and  adds  the  use  of  quantitative  data  to 
guide  the  deployment  and  to  determine  the  value  of  the  improvements 
with  respect  to  quality  and  process  performance  objectives. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  planning  the  deployment  of  organizational  process 
assets. 

This  specific  practice  plans  the  deployment  of  individual  process  and 
technology  improvements.  The  Plan  the  Process  generic  practice 
addresses  comprehensive  planning  that  covers  the  specific  practices  in 
this  process  area. 

Typical  Acquirer  Work  Products 

1 .  Deployment  plan  for  selected  process  and  technology 
improvements 

Subpractices 

1 .  Determine  how  each  process  and  technology  improvement  must 
be  adjusted  for  organization-wide  deployment. 

Process  and  technology  improvements  proposed  within  a  limited  context  (e.g.,  for 
a  single  project)  might  have  to  be  modified  to  work  across  the  organization,  [acqi 
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2.  Determine  the  changes  necessary  to  deploy  each  process  and 
technology  improvement. 


Examples  of  changes  needed  to  deploy  a  process  and  technology  improvement 
include  the  following:  [acqj 

•  Process  descriptions,  standards,  and  procedures 

•  Work  environments 

•  Education  and  training 

•  Skills 

•  Existing  commitments 

•  Existing  activities 

•  Continuing  support  to  end  users 

•  Organizational  culture  and  characteristics 

•  Supplier  agreements 


3.  Identify  strategies  to  address  potential  barriers  to  deploying  each 
process  and  technology  improvement. 

4.  Establish  measures  and  objectives  for  determining  the  value  of 
each  process  and  technology  improvement  with  respect  to  the 
organization’s  quality  and  process-performance  objectives. 


Examples  of  measures  for  determining  the  value  of  a  process  and  technology 
improvement  include  the  following:  [acqi 

•  Return  on  investment 

•  Time  to  recover  the  cost  of  the  process  or  technology  improvement 

•  Measured  improvement  in  the  project’s  or  organization’s  process  performance 

•  Number  and  types  of  project  and  organizational  risks  mitigated  by  the  process  or 
technology  improvement 

•  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations, 
and  the  business  environment 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

5.  Document  the  plan  for  deploying  each  process  and  technology 
improvement. 

6.  Review  and  get  agreement  with  relevant  stakeholders  on  the  plan 
for  deploying  each  process  and  technology  improvement. 
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7.  Revise  the  plan  for  deploying  each  process  and  technology 
improvement  as  necessary. 


SP  2.2  Manage  the  Deployment 

Manage  the  deployment  of  the  selected  process  and 
technology  improvements. 


The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects).  The  primary  difference  is  that  in  the  Causal  Analysis 
and  Resolution  process  area,  planning  is  done  to  manage  the  removal 
of  the  root  causes  of  defects  or  problems  from  the  project’s  defined 
processes.  In  the  Organizational  Innovation  and  Deployment  process 
area,  planning  is  done  to  manage  the  deployment  of  improvements  to 
the  organization’s  processes  and  technologies  that  can  be  quantified 
against  the  organization’s  business  objectives. 

Typical  Acquirer  Work  Products 

1 .  Updated  training  materials  (to  reflect  deployed  process  and 
technology  improvements) 

2.  Documented  results  of  process-  and  technology-improvement 
deployment  activities 

3.  Revised  process-  and  technology-improvement  measures, 
objectives,  priorities,  and  deployment  plans 

Subpractices 

1 .  Monitor  the  deployment  of  the  process  and  technology 
improvements  using  the  deployment  plan. 

2.  Coordinate  the  deployment  of  process  and  technology 
improvements  across  the  organization. 

Coordinating  deployment  includes  the  following  activities:  [acq] 

•  Coordinating  the  activities  of  projects,  support  groups,  and  organizational  groups 
for  each  process  and  technology  improvement 

•  Coordinating  the  activities  for  deploying  related  process  and  technology 
improvements 

3.  Quickly  deploy  process  and  technology  improvements  in  a 
controlled  and  disciplined  manner,  as  appropriate. 
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Examples  of  methods  for  quickly  deploying  process  and  technology  improvements 

include  the  following:  [acqj 

•  Using  red-lines,  process  change  notices,  or  other  controlled  process 
documentation  as  interim  process  descriptions 

•  Deploying  process  and  technology  improvements  incrementally,  rather  than  as  a 
single  deployment 

•  Providing  comprehensive  consulting  to  early  adopters  of  the  process  and 
technology  improvement  in  lieu  of  revised  formal  training 


4.  Incorporate  the  process  and  technology  improvements  into 
organizational  process  assets,  as  appropriate. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  organizational  process  assets. 

5.  Coordinate  the  deployment  of  the  process  and  technology 
improvements  into  the  projects'  defined  processes  as  appropriate. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets. 

6.  Provide  consulting,  as  appropriate,  to  support  deployment  of  the 
process  and  technology  improvements. 

7.  Provide  updated  training  materials  to  reflect  the  improvements  to 
the  organizational  process  assets. 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  training  materials. 

8.  Confirm  that  the  deployment  of  all  process  and  technology 
improvements  is  completed. 

9.  Determine  whether  the  ability  of  the  defined  process  to  meet 
quality  and  process-performance  objectives  is  adversely  affected 
by  the  process  and  technology  improvement,  and  take  corrective 
action  as  necessary. 

Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  quantitatively  managing  the  project’s 
defined  process  to  achieve  the  project’s  established  quality  and 
process-performance  objectives. 

10.  Document  and  review  the  results  of  process-  and  technology- 
improvement  deployment. 

Documenting  and  reviewing  the  results  includes  the  following:  [acqj 
•  Identifying  and  documenting  lessons  learned 
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•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals 

•  Revising  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 

SP  2.3  Measure  Improvement  Effects 

Measure  the  effects  of  the  deployed  process  and  technology 
improvements. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Evaluate  the  Effect  of  Changes  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects). 

Typical  Acquirer  Work  Products 

1 .  Documented  measures  of  the  effects  resulting  from  the  deployed 
process  and  technology  improvements 

Subpractices 

1 .  Measure  the  actual  cost,  effort,  and  schedule  for  deploying  each 
process  and  technology  improvement. 

2.  Measure  the  value  of  each  process  and  technology  improvement. 

3.  Measure  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives. 

4.  Analyze  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives  and  take  corrective  action  as 
needed. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  analyses. 

5.  Store  the  measures  in  the  organization’s  measurement  repository. 
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ORGANIZATIONAL  PROCESS  DEFINITION 

A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Definition  (OPD)  is  to  establish 
and  maintain  a  usable  set  of  organizational  process  assets  and  work 
environment  standards. 


Introductory  Notes 


Organizational  process  assets  enable  consistent  process  performance 
across  the  organization  and  provide  a  basis  for  cumulative,  long-term 
benefits  to  the  organization.  (See  the  definition  of  “organizational 
process  assets”  in  the  glossary.) 

The  organization’s  process  asset  library  is  a  collection  of  items 
maintained  by  the  organization  for  use  by  the  people  and  projects  of  the 
organization.  This  collection  of  items  includes  descriptions  of  processes 
and  process  elements,  descriptions  of  life-cycle  models,  process 
tailoring  guidelines,  process-related  documentation,  and  data.  The 
organization’s  process  asset  library  supports  organizational  learning 
and  process  improvement  by  allowing  the  sharing  of  best  practices  and 
lessons  learned  across  the  organization. 

The  acquirer’s  set  of  standard  processes  also  describes  standard 
interactions  with  suppliers.  Supplier  interactions  are  typically  identified 
in  terms  of  deliverables  expected  from  suppliers,  acceptance  criteria 
applicable  to  those  deliverables,  standards  (e.g.,  architecture  and 
technology  standards),  and  standard  milestone  and  progress  reviews. 

[ACQ] 


The  organization’s  set  of  standard  processes  is  tailored  by  projects  to 
create  their  defined  processes.  The  other  organizational  process  assets 
are  used  to  support  tailoring  as  well  as  the  implementation  of  the 
defined  processes.  The  work  environment  standards  are  used  to  create 
the  project  work  environment. 

A  standard  process  is  composed  of  other  processes  or  process 
elements.  A  process  element  is  the  fundamental  (e.g.,  atomic)  unit  of 
process  definition  and  describes  the  activities  and  tasks  to  consistently 
perform  work.  Process  architecture  provides  rules  for  connecting  the 
process  elements  of  a  standard  process.  The  organization’s  set  of 
standard  processes  may  include  multiple  process  architectures. 
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(See  the  definitions  of  “standard  process,”  “process  architecture,”  and 
“process  element”  in  the  glossary.) 


The  organizational  process  assets  may  be  organized  in  many  ways,  depending  on  the 
implementation  of  the  Organizational  Process  Definition  process  area.  Examples 
include  the  following: 

•  Descriptions  of  life-cycle  models  may  be  documented  as  part  of  the  organization’s 
set  of  standard  processes,  or  they  may  be  documented  separately. 

•  The  organization’s  set  of  standard  processes  may  be  stored  in  the  organization’s 
process  asset  library,  or  they  may  be  stored  separately. 

•  A  single  repository  may  contain  both  the  measurements  and  the  process-related 
documentation,  or  they  may  be  stored  separately. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process-related  matters. 


Specific  Goal  and  Practice  Summary 


SG  1  Establish  Organizational  Process  Assets 
Establish  Standard  Processes 
Establish  Life-Cycle  Model  Descriptions 
Establish  Tailoring  Criteria  and  Guidelines 
Establish  the  Organization's  Measurement 
Repository 

Establish  the  Organization's  Process  Asset  Library 
Establish  Work  Environment  Standards 


SP 

1.1 

SP 

1.2 

SP 

1.3 

SP 

1.4 

SP 

1.5 

SP 

1.6 

Specific  Practices  by  Goal 


SG  1  Establish  Organizational  Process  Assets 

A  set  of  organizational  process  assets  is  established  and  maintained. 

SP  1.1  Establish  Standard  Processes 

Establish  and  maintain  the  organization's  set  of  standard 
processes. 
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Standard  processes  may  be  defined  at  multiple  levels  in  an  enterprise 
and  they  may  be  related  in  a  hierarchical  manner.  For  example,  an 
enterprise  may  have  a  set  of  standard  processes  that  is  tailored  by 
individual  organizations  (e.g.,  a  division  or  site)  in  the  enterprise  to 
establish  their  set  of  standard  processes.  The  set  of  standard 
processes  may  also  be  tailored  for  each  of  the  organization’s  business 
areas  or  product  lines.  Thus  “the  organization’s  set  of  standard 
processes”  can  refer  to  the  standard  processes  established  at  the 
organization  level  and  standard  processes  that  may  be  established  at 
lower  levels,  although  some  organizations  may  only  have  a  single  level 
of  standard  processes.  (See  the  definitions  of  “standard  process”  and 
“organization’s  set  of  standard  processes”  in  the  glossary.) 

Multiple  standard  processes  may  be  needed  to  address  the  needs  of 
different  application  domains,  life-cycle  models,  methodologies,  and 
tools.  The  organization’s  set  of  standard  processes  contains  process 
elements  (e.g.,  a  work  product  size-estimating  element)  that  may  be 
interconnected  according  to  one  or  more  process  architectures  that 
describe  the  relationships  among  these  process  elements.  Processes 
may  be  composed  of  other  processes  or  process  elements,  [acqj 

The  organization’s  set  of  standard  processes  typically  includes 
technical,  management,  administrative,  support,  and  organizational 
processes. 

Basing  standard  processes  on  industry  standards  and  widely  accepted 
models,  with  common  terminology  and  lexicon,  enables  seamless 
interactions  between  acquirer  and  supplier.  In  a  multi-supplier 
environment,  this  is  most  important  for  the  standard  processes  of  the 
acquirer  that  directly  interface  with  the  supplier  processes.  Also,  there 
may  be  cost  and  coordination  benefits  from  having  suppliers  work 
together  to  develop  or  reconcile  common  support  processes  that  are 
aligned  with  the  acquirer's  processes,  [acqj 

The  level  of  detail  required  for  standard  processes  depends  on  the 
flexibility  needed  by  an  enterprise,  for  instance,  based  on  differences  in 
business  context,  project  types,  and  application  domains,  [acq] 

The  organization’s  set  of  standard  processes  should  collectively  cover 
all  processes  needed  by  the  organization  and  projects,  including  those 
processes  addressed  by  the  process  areas  at  Maturity  Level  2. 

Typical  Acquirer  Work  Products 

1 .  Organization's  set  of  standard  processes 

Typical  Supplier  Deliverables 

1 .  Standard  supplier  processes  that  interface  with  acquirer’s 
processes  [acq] 
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Subpractices 

1.  Decompose  each  standard  process  into  constituent  process 
elements  to  the  detail  needed  to  understand  and  describe  the 
process. 

Each  process  element  covers  a  bounded  and  closely  related  set  of  activities.  The 
descriptions  of  the  process  elements  may  be  templates  to  be  filled  in,  fragments 
to  be  completed,  abstractions  to  be  refined,  or  complete  descriptions  to  be  tailored 
or  used  unmodified.  These  elements  are  described  in  sufficient  detail  such  that 
the  process,  when  fully  defined,  can  be  consistently  performed  by  appropriately 
trained  and  skilled  people. 


Examples  of  process  elements  include  the  following:  [acqi 

•  Template  for  conduct  of  management  reviews 

•  Templates  for  supplier  deliverables 

•  Common  lexicon  for  directly  interfacing  acquirer  and  supplier  processes 

•  Templates  for  standard  supplier  agreements 

•  Description  of  method  for  verifying  supplier  estimates 

•  Description  of  standard  acquisition  approaches 

•  Description  of  standard  acceptance  criteria 


2.  Specify  the  critical  attributes  of  each  process  element. 

Examples  of  critical  attributes  include  the  following:  [acqi 

i  •  Process  roles 
|  •  Applicable  standards 

|  •  Applicable  procedures,  methods,  tools,  and  resources 
:  •  Process  performance  objectives 
i  •  Entry  criteria 
j  •  Inputs 

i  •  Product  and  process  measures  to  be  collected  and  used 
:  •  Verification  points 
j  •  Outputs 
j  •  Interfaces 
•  Exit  criteria 

3.  Specify  the  relationships  of  the  process  elements. 
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Examples  of  relationships  include  the  following: 

•  Ordering  of  the  process  elements 

•  Interfaces  among  the  process  elements 

•  Interfaces  with  external  processes 

•  Interdependencies  among  the  process  elements 


The  rules  for  describing  the  relationships  among  process  elements  are  referred  to 
as  “process  architecture."  The  process  architecture  covers  the  essential 
requirements  and  guidelines.  The  detailed  specifications  of  these  relationships  are 
covered  in  the  descriptions  of  the  defined  processes  that  are  tailored  from  the 
organization’s  set  of  standard  processes. 

4.  Ensure  that  the  organization's  set  of  standard  processes  adheres 
to  applicable  policies,  standards  and  models. 

Adherence  to  applicable  process  standards  and  models  is  typically  demonstrated 
by  developing  a  mapping  from  the  organization’s  set  of  standard  processes  to  the 
relevant  process  standards  and  models.  In  addition,  this  mapping  will  be  a  useful 
input  to  future  appraisals. 

5.  Ensure  that  the  organization’s  set  of  standard  processes  satisfies 
the  process  needs  and  objectives  of  the  organization. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  establishing  and  maintaining  the  organization’s 
process  needs  and  objectives. 

6.  Ensure  that  there  is  appropriate  integration  among  the  processes 
that  are  included  in  the  organization’s  set  of  standard  processes. 

7.  Document  the  organization's  set  of  standard  processes. 

8.  Conduct  peer  reviews  on  the  organization's  set  of  standard 
processes. 

The  acquirer’s  review  of  its  standard  processes  can  include  the  participation  of 
suppliers  for  those  processes  and  process  elements  that  define  standard 
interactions  with  suppliers,  [acqi 

9.  Revise  the  organization's  set  of  standard  processes  as  necessary. 


SP  1.2  Establish  Life-Cycle  Model  Descriptions 

Establish  and  maintain  descriptions  of  the  life-cycle  models 
approved  for  use  in  the  organization. 
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Life-cycle  models  may  be  developed  for  a  variety  of  customers  or  in  a 
variety  of  situations,  since  one  life-cycle  model  may  not  be  appropriate 
for  all  situations.  The  organization  may  identify  more  than  one  life-cycle 
model  for  use.  Typically,  the  organization  needs  life-cycle  models  for 
the  types  of  products  and  services  that  it  delivers  and  to  define  the 
phases  of  the  project. 

The  lifecycle  models  describe  acquisition  lifecycles,  depending  on  the 
specific  acquisition  strategy  chosen.  The  acquisition  life-cycle  typically 
begins  with  the  pre-award  phase  of  a  supplier  agreement,  continues 
through  the  phases  of  awarding  and  managing  the  supplier  agreement, 
and  ends  when  the  supplier  agreement  period  of  performance  ends, 
usually  with  the  acceptance  and  completion  of  the  warranty  for  the 
acquired  product  and  the  transition  of  the  product  to  the  support 
organization,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Descriptions  of  life-cycle  models 

Subpractices 

1 .  Select  life-cycle  models  based  on  the  needs  of  projects  and  the 
organization. 


:  Examples  of  project  characteristics  that  could  affect  life-cycle  models  include  the 
i  following:  [acqi 

|  •  Size  of  the  project 

i  •  Experience  and  familiarity  of  project  staff  in  implementing  the  process 
:  •  Constraints  such  as  schedule  and  acceptable  defect  levels 

2.  Document  the  descriptions  of  the  life-cycle  models. 

The  life-cycle  models  may  be  documented  as  part  of  the  organization’s  standard 
process  descriptions  or  they  may  be  documented  separately. 

3.  Conduct  peer  reviews  on  the  life-cycle  models. 

The  acquirer’s  review  of  life  cycle  models  should  include  the  participation  of 
suppliers  for  those  processes  and  process  elements  that  define  expectations  and 
constraints  for  suppliers,  [acqj 

4.  Revise  the  descriptions  of  the  life-cycle  models  as  necessary. 


SP  1.3  Establish  Tailoring  Criteria  and  Guidelines 

Establish  and  maintain  the  tailoring  criteria  and  guidelines  for 
the  organization's  set  of  standard  processes. 
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The  tailoring  criteria  and  guidelines  describe  the  following: 

•  How  the  organization’s  set  of  standard  processes  and 
organizational  process  assets  are  used  to  create  the  defined 
processes 

•  Mandatory  requirements  that  must  be  satisfied  by  the  defined 
processes  (e.g.,  the  subset  of  the  organizational  process  assets 
that  are  essential  for  any  defined  process) 

•  Options  that  can  be  exercised  and  criteria  for  selecting  among  the 
options 

•  Procedures  that  must  be  followed  in  performing  and  documenting 
process  tailoring 

Examples  of  reasons  for  tailoring  include  the  following:  [acqj 

•  Adapting  the  process  for  a  new  supplier 

•  Customizing  the  process  for  a  specific  application  or  class  of  applications  (e.g., 
initial  development,  maintenance,  or  creation  of  prototypes) 

•  Elaborating  the  process  description  so  that  the  resulting  defined  process  can  be 
performed 

•  Supplier  characteristics  like  number  of  projects  executed  for  the  acquirer, 
supplier’s  process  maturity 

•  Acquisition  strategy 


Flexibility  in  tailoring  and  defining  processes  is  balanced  with  ensuring 
appropriate  consistency  in  the  processes  across  the  organization. 
Flexibility  is  needed  to  address  contextual  variables  such  as  the 
domain;  nature  of  the  customer;  cost,  schedule,  and  quality  tradeoffs; 
technical  difficulty  of  the  work;  and  experience  of  the  people 
implementing  the  process.  Consistency  across  the  organization  is 
needed  so  that  organizational  standards,  objectives,  and  strategies  are 
appropriately  addressed,  and  process  data  and  lessons  learned  can  be 
shared. 

Tailoring  is  a  critical  activity  to  allow  for  controlled  changes  to  the 
processes  due  to  specific  needs  of  a  project  or  a  part  of  the 
organization.  Processes  and  process  elements  that  are  more  directly 
related  to  critical  business  goals  and  objectives  should  usually  be 
defined  as  mandatory  (allowing  less  variation),  but  processes  and 
process  elements  that  are  less  critical  or  only  indirectly  affect  business 
objectives  may  allow  for  more  tailoring  (and  therefore  more  variation).  It 
could  also  depend  on  the  life-cycle  model  of  the  project,  the  supplier,  or 
the  acquirer-supplier  relationship,  [acqj 

Tailoring  criteria  and  guidelines  may  allow  for  using  a  standard  process 
“as  is,”  with  no  tailoring. 
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Typical  Acquirer  Work  Products 

1 .  Tailoring  guidelines  for  the  organization's  set  of  standard 
processes 

Subpractices 

1 .  Specify  the  selection  criteria  and  procedures  for  tailoring  the 
organization's  set  of  standard  processes. 

To  fully  leverage  the  supplier’s  process  capability,  the  acquirer  may  choose  to 
minimize  the  tailoring  of  the  supplier’s  standard  processes  due  to  the  acquirer’s 
processes.  Depending  on  the  interfaces  of  the  acquirer’s  processes  with  the 
supplier’s  processes,  the  acquirer’s  standard  processes  may  need  to  be  tailored 
to  allow  the  supplier  to  execute  their  standard  processes,  [acq] 

Examples  of  criteria  and  procedures  include  the  following:  [acqi 

i  •  Criteria  for  selecting  life-cycle  models  from  those  approved  by  the  organization 

I  •  Criteria  for  selecting  process  elements  from  the  organization’s  set  of  standard 
processes 

|  •  Procedures  for  tailoring  the  selected  life-cycle  models  and  process  elements  to 
|  accommodate  specific  process  characteristics  and  needs 

:  •  Criteria  for  selecting  acquisition  strategy  and  suppliers 

i  •  Criteria  for  selecting  acquirer  processes  based  on  supplier  process  tailoring  like 
adding  or  combining  testing  cycles 


:  Examples  of  tailoring  actions  include  the  following:  [acqi 

i  •  Modifying  a  life-cycle  model 
:  •  Combining  elements  of  different  life-cycle  models 
:  •  Modifying  process  elements 
|  •  Replacing  process  elements 
:  •  Reordering  process  elements 

2.  Specify  the  standards  for  documenting  the  defined  processes. 

3.  Specify  the  procedures  for  submitting  and  obtaining  approval  of 
waivers  from  the  requirements  of  the  organization’s  set  of  standard 
processes. 

4.  Document  the  tailoring  guidelines  for  the  organization's  set  of 
standard  processes. 

5.  Conduct  peer  reviews  on  the  tailoring  guidelines. 

6.  Revise  the  tailoring  guidelines  as  necessary. 
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SP  1.4  Establish  the  Organization’s  Measurement  Repository 

Establish  and  maintain  the  organization’s  measurement 
repository. 


Refer  to  the  Use  Organizational  Process  Assets  for  Planning  Project 
Activities  specific  practice  of  the  Integrated  Project  Management 
process  area  for  more  information  about  the  use  of  the  organization’s 
measurement  repository  in  planning  project  activities. 

The  repository  contains  both  product  and  process  measures  that  are 
related  to  the  organization’s  set  of  standard  processes.  It  also  contains 
or  refers  to  the  information  needed  to  understand  and  interpret  the 
measures  and  assess  them  for  reasonableness  and  applicability.  For 
example,  the  definitions  of  the  measures  are  used  to  compare  similar 
measures  from  different  processes. 

Standard  measures  that  need  to  be  collected  from  the  supplier  are 
included  as  requirements  in  the  standard  supplier  agreements,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Definition  of  the  common  set  of  product  and  process  measures  for 
the  organization’s  set  of  standard  processes 

2.  Design  of  the  organization’s  measurement  repository 

3.  Organization's  measurement  repository  (that  is,  the  repository 
structure  and  support  environment) 

4.  Organization’s  measurement  data 
Subpractices 

1 .  Determine  the  organization's  needs  for  storing,  retrieving,  and 
analyzing  measurements. 

2.  Define  a  common  set  of  process  and  product  measures  for  the 
organization's  set  of  standard  processes. 

The  measures  in  the  common  set  are  selected  based  on  the  organization’s  set  of 
standard  processes.  They  are  selected  for  their  ability  to  provide  visibility  into 
process  performance  to  support  expected  business  objectives.  The  common  set 
of  measures  may  vary  for  different  standard  processes. 

The  standard  measures  are  selected  for  their  ability  to  provide  visibility  into 
processes  critical  to  support  expected  business  objectives  and  help  focus  on 
elements  significantly  impacting  the  performance  within  a  project  and  across  the 
organization,  [acqi 

The  measures  defined  include  measures  related  to  acquisition  management, 
some  of  which  may  need  to  be  collected  from  the  suppliers,  [acqi 
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Operational  definitions  for  the  measures  specify  the  procedures  for  collecting  valid 
data  and  the  point  in  the  process  where  the  data  will  be  collected. 


Examples  of  classes  of  commonly  used  acquirer  measures  include  the  following: 

i  [ACQ] 

:  •  Requirements  Volatility 
:  •  Return  on  Investment 
i  •  Cost  Performance  Index 

|  •  Number  of  Defects  Per  Phase  and/or  by  severity  of  defects 
:  •  Schedule  Performance  Index 
i  •  Customer  Satisfaction  Trends 
•  Supplier  Performance  and  Relationship  Trends 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures. 

3.  Design  and  implement  the  measurement  repository. 

4.  Specify  the  procedures  for  storing,  updating,  and  retrieving 
measures. 

5.  Conduct  peer  reviews  on  the  definitions  of  the  common  set  of 
measures  and  the  procedures  for  storing  and  retrieving  measures. 

6.  Enter  the  specified  measures  into  the  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting  and  analyzing  data. 

7.  Make  the  contents  of  the  measurement  repository  available  for  use 
by  the  organization  and  projects  as  appropriate. 

8.  Revise  the  measurement  repository,  common  set  of  measures,  and 
procedures  as  the  organization’s  needs  change. 


Examples  of  when  the  common  set  of  measures  may  need  to  be  revised  include 
the  following: 

•  New  processes  are  added 

•  Processes  are  revised  and  new  measures  are  needed 

•  Finer  granularity  of  data  is  required 

•  Greater  visibility  into  the  process  is  required 

•  Measures  are  retired 


SP  1.5  Establish  the  Organization’s  Process  Asset  Library 

Establish  and  maintain  the  organization's  process  asset  library. 
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Examples  of  items  to  be  stored  in  the  organization’s  process  asset  library  include  the 
following: 

•  Organizational  policies 

•  Defined  process  descriptions 

•  Procedures  (e.g.,  estimating  procedure) 

•  Development  plans 

•  Acquisition  plans 

•  Quality  assurance  plans 

•  Training  materials 

•  Process  aids  (e.g.,  checklists) 

•  Lessons-learned  reports 

Typical  Acquirer  Work  Products 

1 .  Design  of  the  organization’s  process  asset  library 

2.  Organization's  process  asset  library 

3.  Selected  items  to  be  included  in  the  organization’s  process  asset 
library 

4.  Catalog  of  items  in  the  organization’s  process  asset  library 
Subpractices 

1 .  Design  and  implement  the  organization’s  process  asset  library, 
including  the  library  structure  and  support  environment. 

2.  Specify  the  criteria  for  including  items  in  the  library. 

The  items  are  selected  based  primarily  on  their  relationship  to  the  organization’s 
set  of  standard  processes. 

3.  Specify  the  procedures  for  storing  and  retrieving  items. 

4.  Enter  the  selected  items  into  the  library  and  catalog  them  for  easy 
reference  and  retrieval. 

5.  Make  the  items  available  for  use  by  the  projects. 

6.  Periodically  review  the  use  of  each  item  and  use  the  results  to 
maintain  the  library  contents. 

7.  Revise  the  organization’s  process  asset  library  as  necessary. 

Examples  of  when  the  library  may  need  to  be  revised  include  the  following: 

•  New  items  are  added 

•  Items  are  retired 
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•  Current  versions  of  items  are  changed 

SP  1.6  Establish  Work  Environment  Standards 

Establish  and  maintain  work  environment  standards. 


Work  environment  standards  allow  the  organization  and  projects  to 
benefit  from  common  tools,  training,  and  maintenance,  as  well  as  cost 
savings  from  volume  purchases.  Work  environment  standards  address 
the  needs  of  all  stakeholders  and  consider  productivity,  cost, 
availability,  security,  and  workplace  health,  safety,  and  ergonomic 
factors.  Work  environment  standards  can  include  guidelines  for  tailoring 
and/or  the  use  of  waivers  that  allow  adaptation  of  the  project’s  work 
environment  to  meet  specific  needs. 


Examples  of  work  environment  standards  include  the  following: 

•  Procedures  for  operation,  safety,  and  security  of  the  work  environment 

•  Standard  workstation  hardware  and  software 

•  Standard  application  software  and  tailoring  guidelines  for  it 

•  Standard  production  and  calibration  equipment 

•  Process  for  requesting  and  approving  tailoring  or  waivers 


Typical  Acquirer  Work  Products 

1 .  Work  environment  standards 

Subpractices 

1 .  Evaluate  commercially-available  work  environment  standards 
appropriate  for  the  organization. 

2.  Adopt  existing  work  environment  standards  and  develop  new  ones 
to  fill  gaps  based  on  the  organization’s  process  needs  and 
objectives. 
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ORGANIZATIONAL  PROCESS  FOCUS 


A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Focus  (OPF)  is  to  plan  and 
implement  organizational  process  improvement  based  on  a  thorough 
understanding  of  the  current  strengths  and  weaknesses  of  the 
organization’s  processes  and  process  assets. 


Introductory  Notes 


The  organization’s  processes  include  all  the  processes  used  by  the 
organization  and  its  projects.  Candidate  improvements  to  the 
organization’s  processes  are  obtained  from  various  sources,  including 
measurement  of  the  processes,  lessons  learned  in  implementing  the 
processes,  results  of  process  appraisals,  results  of  product  evaluation 
activities,  results  of  benchmarking  against  other  organizations’ 
processes,  and  recommendations  from  other  improvement  initiatives  in 
the  organization. 

Process  improvement  occurs  within  the  context  of  the  organization’s 
needs  and  is  used  to  address  the  organization’s  objectives.  The 
organization  encourages  participation  in  process  improvement  activities 
by  those  who  will  perform  the  process.  The  responsibility  for  facilitating 
and  managing  the  organization’s  process  improvement  activities, 
including  coordinating  the  participation  of  others,  is  typically  assigned  to 
a  process  group.  The  organization  provides  the  long-term  commitment 
and  resources  required  to  sponsor  this  group. 

The  acquirer  encourages  participation  of  suppliers  in  process 
improvement  activities,  [acq] 
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Careful  planning  is  required  to  ensure  that  process  improvement  efforts 
across  the  organization  are  adequately  managed  and  implemented. 

The  organization’s  planning  for  process  improvement  results  in  a 
process  improvement  plan.  The  organization’s  process  improvement 
plan  will  address  appraisal  planning,  process  action  planning,  pilot 
planning,  and  deployment  planning.  Appraisal  plans  describe  the 
appraisal  time  line  and  schedule,  the  scope  of  the  appraisal,  the 
resources  required  to  perform  the  appraisal,  the  reference  model 
against  which  the  appraisal  will  be  performed,  and  the  logistics  for  the 
appraisal.  Process  action  plans  usually  result  from  appraisals  and 
document  how  specific  improvements  targeting  the  weaknesses 
uncovered  by  an  appraisal  will  be  implemented.  In  cases  in  which  it  is 
determined  that  the  improvement  described  in  the  process  action  plan 
should  be  tested  on  a  small  group  before  deploying  it  across  the 
organization,  a  pilot  plan  is  generated.  Finally,  when  the  improvement  is 
to  be  deployed,  a  deployment  plan  is  used.  This  plan  describes  when 
and  how  the  improvement  will  be  deployed  across  the  organization. 

Organizational  process  assets  are  used  to  describe,  implement,  and 
improve  the  organization’s  processes  (see  the  definition  of 
“organizational  process  assets”  in  the  glossary). 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  coordination  of  training,  [acq] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  measures,  [acq] 
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Specific  Goal  and  Practice  Summary 

SG  1  Determine  Process-Improvement  Opportunities 

SP  1.1  Establish  Organizational  Process  Needs 

SP  1 .2  Appraise  the  Organization’s  Processes 

SP  1 .3  Identify  the  Organization's  Process  Improvements 

SG  2  Plan  and  Implement  Process  Improvement  Activities 
SP  2.1  Establish  Process  Action  Plans 
SP  2.2  Implement  Process  Action  Plans 
SP  2.3  Deploy  Organizational  Process  Assets 
SP  2.4  Incorporate  Process-Related  Experiences  into  the 
Organizational  Process  Assets 

Specific  Practices  by  Goal 


SG  1  Determine  Process-Improvement  Opportunities 

Strengths,  weaknesses,  and  improvement  opportunities  for  the 
organization's  processes  are  identified  periodically  and  as  needed. 

Strengths,  weaknesses,  and  improvement  opportunities  may  be 
determined  relative  to  a  process  standard  or  model  such  as  a  CMMI 
model  or  International  Organization  for  Standardization  (ISO)  standard. 
The  process  improvements  should  be  selected  specifically  to  address 
the  organization’s  needs. 

Changing  business  objectives,  legal  and  regulatory  requirements,  and 
results  of  benchmarking  studies  may  be  a  source  of  process 
improvement  opportunities,  [acqi 


SP  1.1  Establish  Organizational  Process  Needs 

Establish  and  maintain  the  description  of  the  process  needs 
and  objectives  for  the  organization. 


The  organization’s  processes  operate  in  a  business  context  that  must 
be  understood.  The  organization’s  business  objectives,  needs,  and 
constraints  determine  the  needs  and  objectives  for  the  organization’s 
processes.  Typically,  the  issues  related  to  financial,  technological, 
quality,  human  resource,  and  marketing  are  important  process 
considerations. 

The  organization’s  process  needs  and  objectives  cover  aspects  that 
include  the  following: 

•  Characteristics  of  the  processes 

•  Process-performance  objectives,  such  as  time-to-market  and 
delivered  quality 

•  Process  effectiveness 
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The  issues  related  to  the  organization’s  acquisition  management  needs 
are  important  process  considerations,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Organization’s  process  needs  and  objectives 

Subpractices 

1 .  Identify  the  policies,  standards,  and  business  objectives  that  are 
applicable  to  the  organization's  processes. 

2.  Examine  relevant  process  standards  and  models  for  best  practices. 

3.  Determine  the  organization’s  process-performance  objectives. 

Process-performance  objectives  may  be  expressed  in  quantitative  or  qualitative 
terms,  [acqi 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurement  objectives,  [acq] 

:  Examples  of  process-performance  objectives  include  the  following:  [acqi 

|  •  Cycle  time 
i  •  Defect  removal  rates 

•  Productivity 

4.  Define  the  essential  characteristics  of  the  organization’s  processes. 

The  essential  characteristics  of  the  organization’s  processes  are  determined 
based  on  the  following:  [acqi 

•  Processes  currently  being  used  in  the  organization 

•  Process  and  product  standards  imposed  by  the  organization 

•  Process  and  product  standards  commonly  imposed  by  customers  of  the 
organization 

Examples  of  process  characteristics  include  the  following:  [acq] 

|  •  Level  of  detail  used  to  describe  the  processes 
|  •  Process  notation  used 

•  Granularity  of  the  processes 

5.  Document  the  organization’s  process  needs  and  objectives. 

6.  Revise  the  organization’s  process  needs  and  objectives  as 
needed. 
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SP  1.2  Appraise  the  Organization’s  Processes 

Appraise  the  organization’s  processes  periodically  and  as 
needed  to  maintain  an  understanding  of  their  strengths  and 
weaknesses. 


Process  appraisals  may  be  performed  for  the  following  reasons: 

•  To  identify  processes  that  should  be  improved 

•  To  confirm  progress  and  make  the  benefits  of  process  improvement 
visible 

•  To  satisfy  the  needs  of  a  customer-supplier  relationship 

•  To  motivate  and  facilitate  buy-in 

The  buy-in  gained  during  a  process  appraisal  can  be  eroded 
significantly  if  it  is  not  followed  by  an  appraisal-based  action  plan. 

Typical  Acquirer  Work  Products 

1 .  Plans  for  the  organization's  process  appraisals 

2.  Appraisal  findings  that  address  strengths  and  weaknesses  of  the 
organization's  processes 

3.  Improvement  recommendations  for  the  organization's  processes 
Subpractices 

1 .  Obtain  sponsorship  of  the  process  appraisal  from  senior 
management. 

Senior  management  sponsorship  includes  the  commitment  to  have  the 
organization's  managers  and  staff  participate  in  the  process  appraisal  and  to 
provide  the  resources  and  funding  to  analyze  and  communicate  the  findings  of  the 
appraisal,  [acqj 

2.  Define  the  scope  of  the  process  appraisal. 

Process  appraisals  may  be  performed  on  the  entire  organization  or  may  be 
performed  on  a  smaller  part  of  an  organization  such  as  a  single  project  or 
business  area,  [acq] 

The  scope  of  the  process  appraisal  addresses  the  following:  [acqi 

•  Definition  of  the  organization  (e.g.,  sites  or  business  areas)  that  will  be  covered  by 
the  appraisal 

•  Identification  of  the  project  and  support  functions  that  will  represent  the 
organization  in  the  appraisal 

•  Processes  that  will  be  appraised 

3.  Determine  the  method  and  criteria  for  process  appraisal. 
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Process  appraisals  can  occur  in  many  forms.  Process  appraisals  should  address 
the  needs  and  objectives  of  the  organization,  which  may  change  over  time.  For 
example,  the  appraisal  may  be  based  on  a  process  model,  such  as  a  CMMI 
model,  or  on  a  national  or  international  standard,  such  as  ISO  9001  [ISO  2000], 
The  appraisals  may  also  be  based  on  a  benchmark  comparison  with  other 
organizations.  The  appraisal  method  may  assume  a  variety  of  characteristics  in 
terms  of  time  and  effort  expended,  makeup  of  the  appraisal  team,  and  the  method 
and  depth  of  investigation,  [acqi 

4.  Plan,  schedule,  and  prepare  for  the  process  appraisal. 

5.  Conduct  the  process  appraisal. 

6.  Document  and  deliver  the  appraisal’s  activities  and  findings. 

SP  1.3  Identify  the  Organization's  Process  Improvements 

Identify  improvements  to  the  organization's  processes  and 

process  assets. 


Typical  Acquirer  Work  Products 

1 .  Analysis  of  candidate  process  improvements 

2.  Identification  of  improvements  for  the  organization's  processes 
Subpractices 

1.  Determine  candidate  process  improvements. 

Candidate  process  improvements  are  typically  determined  by  doing  the  following: 

[ACQ] 


•  Measure  the  processes  and  analyze  the  measurement  results 

•  Review  the  processes  for  effectiveness  and  suitability 

•  Review  the  lessons  learned  from  tailoring  the  organization’s  set  of  standard 
processes 

•  Review  the  lessons  learned  from  implementing  the  processes 

•  Review  process  improvement  proposals  submitted  by  the  organization’s 
managers  and  staff,  and  other  relevant  stakeholders 

•  Solicit  inputs  on  process  improvements  from  senior  management  and  leaders  in 
the  organization 

•  Examine  the  results  of  process  appraisals  and  other  process-related  reviews 

•  Review  results  of  other  organization  improvement  initiatives 

Candidate  process  improvements  are  also  determined  by  doing  the  following:  [acqi 

•  Review  process-improvement  proposals  submitted  by  the  organization's  suppliers 

•  Obtain  feedback  from  suppliers  on  acquirer  processes  and  supplier-acquirer 
interface  points 

2.  Prioritize  the  candidate  process  improvements. 
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Criteria  for  prioritization  are  as  follows:  [acqj 

•  Consider  the  estimated  cost  and  effort  to  implement  the  process  improvements 

•  Appraise  the  expected  improvement  against  the  organization’s  improvement 
objectives  and  priorities 

•  Determine  the  potential  barriers  to  the  process  improvements  and  develop 
strategies  for  overcoming  these  barriers 

:  Examples  of  techniques  to  help  determine  and  prioritize  the  possible 
j  improvements  to  be  implemented  include  the  following:  [acqj 

:  •  A  gap  analysis  that  compares  current  conditions  in  the  organization  with  optimal 
:  conditions 

:  •  Force-field  analysis  of  potential  improvements  to  identify  potential  barriers  and 
:  strategies  for  overcoming  those  barriers 

j  •  Cause-and-effect  analyses  to  provide  information  on  the  potential  effects  of 
different  improvements  that  can  then  be  compared 


3.  Identify  and  document  the  process  improvements  that  will  be 
implemented. 

4.  Revise  the  list  of  planned  process  improvements  to  keep  it  current. 


SG  2  Plan  and  Implement  Process  Improvement  Activities 

Improvements  are  planned  and  implemented,  organizational  process 
assets  are  deployed,  and  process-related  experiences  are  incorporated 
into  the  organizational  process  assets. 

Successful  implementation  of  improvements  requires  participation  in  the 
process  definition  and  improvement  activities  by  process  owners,  those 
performing  the  process,  and  support  organizations. 


SP  2.1  Establish  Process  Action  Plans 

Establish  and  maintain  process  action  plans  to  address 
improvements  to  the  organization's  processes  and  process 
assets. 


Establishing  and  maintaining  process  action  plans  typically  involves  the 
following  roles: 

•  Management  steering  committees  to  set  strategies  and  oversee 
process  improvement  activities 

•  Process  group  staff  to  facilitate  and  manage  the  process 
improvement  activities 

•  Process  action  teams  to  define  and  implement  the  improvement 

•  Process  owners  to  manage  the  deployment 

•  Practitioners  to  perform  the  process 
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This  involvement  helps  to  obtain  buy-in  on  the  process  improvements 
and  increases  the  likelihood  of  effective  deployment. 

Process  action  plans  are  detailed  implementation  plans.  These  plans 
differ  from  the  organization’s  process  improvement  plan  in  that  they  are 
plans  targeting  specific  improvements  that  have  been  defined  to 
address  weaknesses  usually  uncovered  by  appraisals. 

Suppliers  may  be  involved  in  developing  the  process  action  plans  if  the 
processes  that  define  interfaces  between  acquirer  and  supplier  are 
targeted  for  improvement,  [acqj 

Typical  Acquirer  Work  Products 

1.  Organization's  approved  process  action  plans 

Subpractices 

1 .  Identify  strategies,  approaches,  and  actions  to  address  the 
identified  process  improvements. 

New,  unproven,  and  major  changes  are  piloted  before  they  are  incorporated  into 
normal  use.  [acqi 

2.  Establish  process  action  teams  to  implement  the  actions. 

The  teams  and  people  performing  the  process  improvement  actions  are  called 
“process  action  teams.”  Process  action  teams  typically  include  process  owners 
and  those  who  perform  the  process,  [acqj 

Process  action  teams  may  include  supplier  representatives  when  suppliers 
interact  with  the  acquirer  process  to  be  improved  or  provide  supplemental 
resources  to  the  acquirer  to  perform  an  acquirer  process,  [acqj 

3.  Document  process  action  plans. 

Process  action  plans  typically  cover  the  following:  [acqi 

•  Process  improvement  infrastructure 

•  Process-improvement  objectives 

•  Process  improvements  that  will  be  addressed 

•  Procedures  for  planning  and  tracking  process  actions 

•  Strategies  for  piloting  and  implementing  the  process  actions 

•  Responsibility  and  authority  for  implementing  the  process  actions 

•  Resources,  schedules,  and  assignments  for  implementing  the  process  actions 

•  Methods  for  determining  the  effectiveness  of  the  process  actions 

•  Risks  associated  with  process  action  plans 

4.  Review  and  negotiate  process  action  plans  with  relevant 
stakeholders. 
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5.  Review  process  action  plans  as  necessary. 

SP  2.2  Implement  Process  Action  Plans 

Implement  process  action  plans  across  the  organization. 


Typical  Acquirer  Work  Products 

1 .  Commitments  among  the  various  process  action  teams 

2.  Status  and  results  of  implementing  process  action  plans 

3.  Plans  for  pilots 

Subpractices 

1 .  Make  process  action  plans  readily  available  to  relevant 
stakeholders. 

2.  Negotiate  and  document  commitments  among  the  process  action 
teams  and  revise  their  process  action  plans  as  necessary. 

3.  Track  progress  and  commitments  against  process  action  plans. 

4.  Conduct  joint  reviews  with  the  process  action  teams  and  relevant 
stakeholders  to  monitor  the  progress  and  results  of  the  process 
actions. 

5.  Plan  pilots  needed  to  test  selected  process  improvements. 

6.  Review  the  activities  and  work  products  of  process  action  teams. 

7.  Identify,  document,  and  track  to  closure  issues  in  implementing 
process  action  plans. 

8.  Ensure  that  the  results  of  implementing  process  action  plans 
satisfy  the  organization’s  process-improvement  objectives. 


SP  2.3  Deploy  Organizational  Process  Assets 

Deploy  organizational  process  assets  across  the  organization. 


Deployment  of  organizational  process  assets  or  of  changes  to 
organizational  process  assets  should  be  performed  in  an  orderly 
manner.  Some  organizational  process  assets  or  changes  to 
organizational  process  assets  may  not  be  appropriate  for 
implementation  in  some  parts  of  the  organization  (because  of  customer 
requirements  or  the  current  life-cycle  phase  being  implemented,  for 
example).  It  is  therefore  important  that  those  that  are  or  will  be 
executing  the  process,  as  well  as  other  organization  functions  (such  as 
training  and  quality  assurance)  be  involved  in  the  deployment  as 
necessary. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  how  the  deployment  of  organizational  process  assets 
is  supported  and  enabled  by  the  organization’s  process  asset  library. 

The  acquirer  defines  in  the  supplier  agreement  how  changes  to 
organizational  process  assets  that  impact  the  supplier  (e.g.,  standard 
supplier  deliverables,  acceptance  criteria)  have  to  be  deployed,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Plans  for  deploying  the  organizational  process  assets  and  changes 
to  organizational  process  assets 

2.  Training  materials  for  deploying  the  organizational  process  assets 
and  changes  to  organizational  process  assets 

3.  Documentation  of  changes  to  the  organizational  process  assets 

4.  Support  materials  for  deploying  the  organizational  process  assets 
and  changes  to  organizational  process  assets 

Subpractices 

1 .  Deploy  organizational  process  assets  and  associated  methods  and 
tools. 

Typical  activities  performed  as  a  part  of  this  deployment  include  the  following:  [acqj 

•  Planning  the  deployment 

•  Identifying  the  organizational  process  assets  that  should  be  adopted  by  those  who 
will  be  performing  the  process 

•  Ensuring  that  training  is  available  for  the  organizational  process  assets  that  are 
being  deployed 

•  Identifying  the  support  resources  (e.g.,  tools)  needed  to  transition  the  deployed 
organizational  process  assets 

•  Determining  the  schedule  for  deploying  the  organizational  process  assets 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  coordination  of  training. 

2.  Deploy  the  changes  that  were  made  to  the  organizational  process 
assets. 

Typical  activities  performed  as  a  part  of  this  deployment  include  the  following:  [acqj 

•  Planning  the  deployment 

•  Determining  which  changes  are  appropriate  for  those  that  are  or  will  be 
performing  the  process 

•  Determining  the  time  frame  for  deploying  the  changes 

•  Arranging  for  the  associated  support  needed  to  successfully  transition  the 
changes 
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3.  Document  the  changes  to  the  organizational  process  assets. 

The  documentation  of  changes  is  used  to  understand  the  relationship  of  the 
changes  to  resulting  changes  in  process  performance  and  results,  [acqi 

4.  Provide  guidance  and  consultation  on  the  use  of  the  organizational 
process  assets. 

SP  2.4  Incorporate  Process-Related  Experiences  into  the  Organizational 
Process  Assets 

Incorporate  process-related  work  products,  measures,  and 
improvement  information  derived  from  planning  and 
performing  the  process  into  the  organizational  process  assets. 


Typical  Acquirer  Work  Products 

1.  Process  improvement  proposals 

2.  Process  lessons  learned 

3.  Measurements  on  the  organizational  process  assets 

4.  Improvement  recommendations  for  the  organizational  process 
assets 

5.  Records  of  the  organization's  process-improvement  activities 

6.  Information  on  the  organizational  process  assets  and 
improvements  to  them 

Subpractices 

1 .  Conduct  periodic  reviews  of  the  effectiveness  and  suitability  of  the 
organization’s  set  of  standard  processes  and  related  organizational 
process  assets  relative  to  the  organization’s  business  objectives. 

2.  Obtain  feedback  about  the  use  of  the  organizational  process 
assets. 

3.  Derive  lessons  learned  from  defining,  piloting,  implementing,  and 
deploying  the  organizational  process  assets. 

4.  Make  lessons  learned  available  to  the  people  in  the  organization  as 
appropriate. 

Actions  may  have  to  be  taken  to  ensure  that  lessons  learned  are  used 
appropriately,  [acqi 


Examples  of  inappropriate  use  of  lessons  learned  include  the  following:  [acqi 

•  Evaluating  the  performance  of  people 

•  Judging  process  performance  or  results 
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Examples  of  ways  to  prevent  inappropriate  use  of  lessons  learned  include  the 
following:  [acq] 

•  Controlling  access  to  the  lessons  learned 

•  Educating  people  about  the  appropriate  use  of  lessons  learned 


5.  Analyze  the  organization's  common  set  of  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  measures. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  an  organizational 
measurement  repository,  including  common  measures. 

6.  Appraise  the  processes,  methods,  and  tools  in  use  in  the 
organization  and  develop  recommendations  for  improving  the 
organizational  process  assets. 

This  appraisal  typically  includes  the  following:  [acqj 

•  Determining  which  of  the  processes,  methods,  and  tools  are  of  potential  use  to 
other  parts  of  the  organization 

•  Appraising  the  quality  and  effectiveness  of  the  organizational  process  assets 

•  Identifying  candidate  improvements  to  the  organizational  process  assets 

•  Determining  compliance  with  the  organization’s  set  of  standard  processes  and 
tailoring  guidelines 

7.  Make  the  best  use  of  the  organization's  processes,  methods,  and 
tools  available  to  the  people  in  the  organization  as  appropriate. 

8.  Manage  process  improvement  proposals. 

Process  improvement  proposals  can  address  both  process  and  technology 
improvements,  [acq] 

The  activities  for  managing  process  improvement  proposals  typically  include  the 
following:  [acq] 

•  Soliciting  process  improvement  proposals 

•  Collecting  process  improvement  proposals 

•  Reviewing  the  process  improvement  proposals 

•  Selecting  the  process  improvement  proposals  that  will  be  implemented 

•  Tracking  the  implementation  of  the  process  improvement  proposals 

Process  improvement  proposals  are  documented  as  process  change  requests  or 
problem  reports,  as  appropriate,  [acq] 
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Some  process  improvement  proposals  may  be  incorporated  into  the 
organization’s  process  action  plans,  [acqj 

9.  Establish  and  maintain  records  of  the  organization's  process 
improvement  activities. 
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ORGANIZATIONAL  PROCESS  PERFORMANCE 

A  Process  Management  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  Organizational  Process  Performance  (OPP)  is  to 
establish  and  maintain  a  quantitative  understanding  of  the  performance 
of  the  organization’s  set  of  standard  processes  in  support  of  quality  and 
process-performance  objectives,  and  to  provide  the  process 
performance  data,  baselines,  and  models  to  quantitatively  manage  the 
organization’s  projects. 


Introductory  Notes 


Process  performance  is  a  measure  of  the  actual  results  achieved  by 
following  a  process.  Process  performance  is  characterized  by  process 
measures  (e.g.,  effort,  cycle  time,  and  defect  removal  effectiveness) 
and  product  measures  (e.g.,  reliability,  defect  density,  capacity, 
response  time,  and  cost). 

The  common  measures  for  the  organization  are  composed  of  process 
and  product  measures  that  can  be  used  to  summarize  the  actual 
performance  of  processes  in  individual  projects  in  the  organization.  The 
organizational  data  for  these  measures  are  analyzed  to  establish  a 
distribution  and  range  of  results,  which  characterize  the  expected 
performance  of  the  process  when  used  on  any  individual  project  in  the 
organization. 

In  this  process  area,  the  phrase  “quality  and  process-performance 
objectives”  covers  objectives  and  requirements  for  product  quality, 
service  quality,  and  process  performance.  As  indicated  above,  the  term 
“process  performance”  includes  quality;  however,  to  emphasize  the 
importance  of  quality,  the  phrase  “quality  and  process-performance 
objectives”  is  used  rather  than  just  “process-performance  objectives.” 

Measuring  quality  and  process-performance  objectives  may  involve 
combining  existing  measures  into  additional  derived  measures  to 
provide  more  insight  into  the  overall  efficiencies  and  effectiveness  at  a 
project,  program,  and  organization  level.  The  analysis  at  the 
organization  level  may  be  used  to  study  productivity,  improve 
efficiencies,  and  increase  throughput  across  projects  within  the 
organization,  [acq] 
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The  expected  process  performance  can  be  used  in  establishing  the 
project’s  quality  and  process-performance  objectives  and  can  be  used 
as  a  baseline  against  which  actual  project  performance  can  be 
compared.  This  information  is  used  to  quantitatively  manage  the 
project.  Each  quantitatively  managed  project,  in  turn,  provides  actual 
performance  results  that  become  a  part  of  the  baseline  data  for  the 
organizational  process  assets. 

The  acquirer  may  use  some  of  the  process  performance  objectives  to 
define  expected  performance  and  service  level  expectations  for  the 
suppliers,  [acq] 

The  associated  process  performance  models  are  used  to  represent 
past  and  current  process  performance  and  to  predict  future  results  of 
the  process.  For  example,  the  latent  defects  in  the  delivered  product 
can  be  predicted  using  measurements  of  defects  identified  during 
product-verification  activities. 

The  same  measures  of  latent  defects,  analyzed  using  a  supplier’s  past 
projects  data,  can  be  used  to  predict  the  quality  of  products  delivered  by 
that  supplier.  The  acquirer  can  incorporate  performance  models  of  the 
supplier(s)  to  predict  the  overall  solution  delivery  capability  of  the 
acquirer,  [acq] 


When  the  organization  has  measures,  data,  and  analytical  techniques 

for  critical  process,  product,  and  service  characteristics,  it  is  able  to  do 

the  following: 

•  Determine  whether  processes  are  behaving  consistently  or  have 
stable  trends  (i.e.,  are  predictable) 

•  Identify  processes  where  the  performance  is  within  natural  bounds 
that  are  consistent  across  process  implementation  teams 

•  Establish  criteria  for  identifying  whether  a  process  or  subprocess 
should  be  statistically  managed,  and  determine  pertinent  measures 
and  analytical  techniques  to  be  used  in  such  management 

•  Identify  processes  that  show  unusual  (e.g.,  sporadic  or 
unpredictable)  behavior 

•  Identify  any  aspects  of  the  processes  that  can  be  improved  in  the 
organization’s  set  of  standard  processes 

•  Identify  the  implementation  of  a  process  which  performs  best 

•  Identify  aspects  of  the  processes  that  could  be  improved  across 
acquirer-supplier  interfaces  [acqj 
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Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process  performance  baselines  and 
models. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measures  and  collecting  and  analyzing 
data. 


Specific  Goal  and  Practice  Summary 


SG  1  Establish  Performance  Baselines  and  Models 
SP  1 .1  Select  Processes 

SP  1 .2  Establish  Process  Performance  Measures 

SP  1 .3  Establish  Quality  and  Process-Performance 
Objectives 

SP  1 .4  Establish  Process  Performance  Baselines 
SP  1 .5  Establish  Process  Performance  Models 


Specific  Practices  by  Goal 


SG  1  Establish  Performance  Baselines  and  Models 

Baselines  and  models  that  characterize  the  expected  process  performance 
of  the  organization's  set  of  standard  processes  are  established  and 
maintained. 

Prior  to  establishing  process  performance  baselines  and  models,  it  is 
necessary  to  determine  which  processes  are  suitable  to  be  measured 
(the  Select  Processes  specific  practice),  which  measures  are  useful  for 
determining  process  performance  (the  Establish  Process  Performance 
Measures  specific  practice),  and  the  quality  and  process-performance 
objectives  for  those  processes  (the  Establish  Quality  and  Process- 
Performance  Objectives  specific  practice).  These  specific  practices  are 
often  interrelated  and  may  need  to  be  performed  concurrently  to  select 
the  appropriate  processes,  measures,  and  quality  and  process- 
performance  objectives.  Often,  the  selection  of  one  process,  measure, 
or  objective  will  constrain  the  selection  of  the  others.  For  example,  if  a 
certain  process  is  selected,  the  measures  and  objectives  for  that 
process  may  be  constrained  by  the  process  itself. 


SP  1.1  Select  Processes 

Select  the  processes  or  subprocesses  in  the  organization's  set 
of  standard  processes  that  are  to  be  included  in  the 
organization's  process  performance  analyses. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  structure  of  the  organizational  process  assets. 
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The  organization’s  set  of  standard  processes  consists  of  a  set  of 
standard  processes  that,  in  turn,  are  composed  of  subprocesses. 

Typically,  it  will  not  be  possible,  useful,  or  economically  justifiable  to 
apply  statistical  management  techniques  to  all  processes  or 
subprocesses  of  the  organization’s  set  of  standard  processes.  Selection 
of  the  processes  and/or  subprocesses  is  based  on  the  needs  and 
objectives  of  both  the  organization  and  projects. 

The  selection  of  subprocesses  for  analysis,  the  determination  of 
process-performance  objectives,  and  the  selection  of  appropriate 
measures  are  often  concurrent  and  iterative  processes  of  both  projects 
and  the  organization. 

When  selecting  the  processes  or  subprocesses  for  analyses,  it  is  critical 
to  understand  the  relationships  between  different  processes  and 
subprocesses  and  their  impact  on  the  acquirer’s  and  supplier’s 
performance  of  delivering  the  product  specified  by  the  customer.  Such 
an  approach  will  help  ensure  that  quantitative  and  statistical 
management  is  applied  to  where  it  will  have  the  most  overall  value  to 
the  organization,  [acq] 


Examples  of  criteria  which  may  be  used  for  the  selection  of  a  subprocess  for 
organizational  analysis  include  the  following: 

•  The  relationship  of  the  subprocess  to  key  business  objectives 

•  Current  availability  of  valid  historical  data  relevant  to  the  subprocess 

•  The  current  degree  of  variability  of  this  data 

•  Subprocess  stability  (e.g.  stable  performance  in  comparable  instances) 

•  The  availability  of  corporate  or  commercial  information  that  can  be  used  to  build 
predictive  models 


The  existence  of  project  data  that  indicates  the  subprocess  has  been  or 
can  be  stabilized  is  a  useful  criterion  for  subprocess  selection. 

Typical  Acquirer  Work  Products 

1 .  List  of  processes  or  subprocesses  identified  for  process 
performance  analyses 


SP  1.2  Establish  Process  Performance  Measures 

Establish  and  maintain  definitions  of  the  measures  that  are  to 
be  included  in  the  organization’s  process  performance 
analyses. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  selecting  measures. 
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Typical  Acquirer  Work  Products 

1 .  List  of  processes  or  subprocesses  identified  for  process 
performance  analyses  [acq] 

2.  Definitions  for  the  selected  measures  of  process  performance 

Typical  Supplier  Deliverables 

1 .  List  of  processes  or  subprocesses  identified  for  process 
performance  analyses,  if  any  [acq] 

Subpractices 

1 .  Determine  which  of  the  organization’s  business  objectives  for 
quality  and  process  performance  need  to  be  addressed  by  the 
measures. 

2.  Select  measures  that  provide  appropriate  insight  into  the 
organization’s  quality  and  process  performance. 

The  measurement  repository  provides  a  list  of  common  measures  for  this 
purpose,  [acq] 

For  those  business  objectives  that  are  met  through  acquisition,  performance 
measures  typically  lead  to  measures  and  related  service  level  expectations  for 
suppliers,  [acq] 


Examples  of  criteria  used  to  select  measures  include  the  following:  [acqi 

•  Relationship  of  the  measures  to  the  organization’s  business  objectives 

•  Coverage  that  the  measures  provide  over  the  entire  life  of  the  product  or  service 

•  Visibility  that  the  measures  provide  into  the  process  performance 

•  Availability  of  the  measures 

•  Extent  to  which  the  measures  are  objective 

•  Frequency  at  which  the  observations  of  the  measure  can  be  collected 

•  Extent  to  which  the  measures  are  controllable  by  changes  to  the  process 

•  Extent  to  which  the  measures  represent  the  users’  view  of  effective  process 
performance 

•  Measures  selected  must  also  include  those  that  provide  insights  into  supplier 
performance  with  respect  to  service  levels  and  effectiveness  of  acquisition 
management  by  acquirer. 


3.  Incorporate  the  selected  measures  into  the  organization’s  set  of 
common  measures. 

Measures  expected  to  be  collected  and  reported  by  suppliers  are  incorporated 
into  standard  supplier  agreement  templates  and  standard  service  level 
agreements,  as  appropriate,  [acqi 
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Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  organizational  process  assets. 

4.  Revise  the  set  of  measures  as  necessary. 

Measures  are  periodically  evaluated  for  their  continued  usefulness  and  ability  to 
indicate  process  effectiveness,  [acqi 


SP  1.3  Establish  Quality  and  Process-Performance  Objectives 

Establish  and  maintain  quantitative  objectives  for  quality  and 
process  performance  for  the  organization. 


The  organization’s  quality  and  process-performance  objectives  should 
have  the  following  attributes: 

•  Based  on  the  organization’s  business  objectives 

•  Based  on  the  past  performance  of  projects 

•  Defined  to  gauge  process  performance  in  areas  such  as  product 
quality,  productivity,  cycle  time,  or  response  time 

•  Constrained  by  the  inherent  variability  or  natural  bounds  of  the 
process 

Typical  Acquirer  Work  Products 

1 .  Organization's  quality  and  process-performance  objectives 

2.  Supplier  service  levels  based  on  quality  and  process-performance 
objectives  [acq] 

Subpractices 

1 .  Review  the  organization’s  business  objectives  related  to  quality 
and  process  performance. 


Examples  of  business  objectives  include  the  following:  [acqi 

•  Delivery  of  functionality  within  a  target  percentage  of  estimated  cost 

•  Achieve  a  development  cycle  of  a  specified  duration  for  a  specified  release  of  a 
product 

•  Decrease  the  cost  of  maintenance  of  the  products  by  a  specified  percent 


2.  Define  the  organization’s  quantitative  objectives  for  quality  and 
process  performance. 

Objectives  may  be  established  for  process  measurements  (e.g.,  effort,  cycle  time, 
and  defect  removal  effectiveness)  as  well  as  for  product  measurements  (e.g., 
reliability  and  defect  density)  and  service  measurements  (e.g.,  capacity  and 
response  times)  where  appropriate,  [acqi 
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Examples  of  quality  and  process-performance  objectives  include  the  following: 

[ACQ] 

•  Achieve  a  specified  productivity 

•  Deliver  work  products  with  no  more  than  a  specified  number  of  latent  defects 

•  Shorter  time  to  delivery  within  +1-5  percent  of  the  process  performance  baseline 

•  Reduced  total  life  cycle  cost  of  new  and  existing  products  by  15  percent 

•  Delivery  100  percent  of  specified  functionality  of  the  product 

•  Improve  supplier  performance  and  relationship  scores  to  4.8  (out  of  5) 


3.  Define  the  priorities  of  the  organization’s  objectives  for  quality  and 
process  performance. 

4.  Review,  negotiate,  and  obtain  commitment  for  the  organization’s 
quality  and  process-performance  objectives  and  their  priorities  from 
the  relevant  stakeholders. 

5.  Revise  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  as  necessary. 


Examples  of  when  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  may  need  to  be  revised  include  the  following:  [acqj 

•  When  the  organization’s  business  objectives  change 

•  When  the  organization’s  processes  change 

•  When  actual  quality  and  process  performance  differs  significantly  from  the 
objectives 


SP  1.4  Establish  Process  Performance  Baselines 

Establish  and  maintain  the  organization's  process  performance 
baselines. 


The  organization’s  process  performance  baselines  are  a  measurement 
of  performance  for  the  organization’s  set  of  standard  processes  at 
various  levels  of  detail,  as  appropriate.  The  processes  include  the 
following: 

•  Sequence  of  connected  processes 

•  Processes  that  cover  the  entire  life  of  the  project 

•  Processes  for  developing  individual  work  products 

There  may  be  several  process  performance  baselines  to  characterize 
performance  for  subgroups  of  the  organization. 
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Examples  of  criteria  used  to  categorize  subgroups  include  the  following:  [acqi 

•  Product  line 

•  Line  of  business 

•  Application  domain 

•  Complexity 

•  Team  size 

•  Work  product  size 

•  Process  elements  from  the  organization’s  set  of  standard  processes 

•  Process  performance  may  be  categorized  additionally  based  on  specific  supplier, 
acquisition  approach,  and  contract  type  (e.g.,  fixed  price  and  time  and  effort) 


Allowable  tailoring  of  the  organization’s  set  of  standard  processes  may 
significantly  affect  the  comparability  of  the  data  for  inclusion  in  process 
performance  baselines.  The  effects  of  tailoring  should  be  considered  in 
establishing  baselines.  Depending  on  the  tailoring  allowed,  separate 
performance  baselines  may  exist  for  each  type  of  tailoring. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process  performance  baselines. 

Typical  Acquirer  Work  Products 

1 .  Baseline  data  on  the  organization’s  process  performance 

Typical  Supplier  Deliverables 

1 .  Supplier’s  process  performance  data  for  performance  objectives 
and  expected  service  levels  [acq] 

Subpractices 

1 .  Collect  measurements  from  the  organization’s  projects. 

The  process  in  use  when  the  measurement  was  taken  is  recorded  to  enable 
appropriate  use  later,  [acqj 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  collecting  and  analyzing  data. 

2.  Establish  and  maintain  the  organization’s  process  performance 
baselines  from  the  collected  measurements  and  analyses. 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 
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Process  performance  baselines  are  derived  by  analyzing  the  collected  measures 
to  establish  a  distribution  and  range  of  results  that  characterize  the  expected 
performance  for  selected  processes  when  used  on  any  individual  project  in  the 
organization,  [acqi 

The  measurements  from  stable  processes  from  projects  should  be  used;  other 
data  may  not  be  reliable,  [acqj 

3.  Review  and  get  agreement  with  relevant  stakeholders  about  the 
organization's  process  performance  baselines. 

4.  Make  the  organization's  process  performance  information  available 
across  the  organization  in  the  organization's  measurement 
repository. 

The  organization’s  process  performance  baselines  are  used  by  the  projects  to 
estimate  the  natural  bounds  for  process  performance,  [acqi 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  the  organization’s 
measurement  repository. 

5.  Compare  the  organization’s  process  performance  baselines  to  the 
associated  objectives. 

6.  Revise  the  organization’s  process  performance  baselines  as 
necessary. 


Examples  of  when  the  organization’s  process  performance  baselines  may  need  to  : 
be  revised  include  the  following:  [acqi  j 

•  When  the  processes  change  : 

•  When  the  organization’s  results  change 

•  When  the  organization’s  needs  change  j 

•  When  suppliers  processes  change 

•  When  suppliers  change 


SP  1.5  Establish  Process  Performance  Models 

Establish  and  maintain  the  process  performance  models  for  the 
organization’s  set  of  standard  processes. 


Process  performance  models  are  used  to  estimate  or  predict  the  value 
of  a  process  performance  measure  from  the  values  of  other  process, 
product,  and  service  measurements.  These  process  performance 
models  typically  use  process  and  product  measurements  collected 
throughout  the  life  of  the  project  to  estimate  progress  toward  achieving 
objectives  that  cannot  be  measured  until  later  in  the  project’s  life. 
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Process  performance  models  are  used  to  estimate  or  predict  when  to 
fund,  hold,  cancel,  migrate,  re-engineer,  or  retire  a  project  or  programs. 
Process  performance  models  allow  the  acquirer  to  synchronize 
processes  with  the  customer’s  needs.  The  organization’s  process 
performance  baselines  provide  quantitative  data  on  those  aspects  of 
the  projects  and  organization  that  can  approximate  the  throughput 
potential  of  its  processes.  Focusing  on  these  critical  constraints, 
process  performance  models  allow  the  acquirer  to  predict  how  to  best 
maximize  the  flow  of  work  through  the  projects  and  the  organization. 

[ACQ] 


The  process  performance  models  are  used  as  follows: 

•  The  organization  uses  them  for  estimating,  analyzing,  and 
predicting  the  process  performance  associated  with  the  processes 
in  the  organization’s  set  of  standard  processes. 

•  The  organization  uses  them  to  assess  the  (potential)  return  on 
investment  for  process  improvement  activities. 

•  Projects  use  them  for  estimating,  analyzing,  and  predicting  the 
process  performance  for  their  defined  processes. 

•  Projects  use  them  for  selecting  processes  for  use. 

Performance  models  are  also  used  to  set  performance  objectives  for 
the  suppliers  and  to  provide  data  that  can  help  suppliers  achieve  these 
objectives,  [acq] 

These  measures  and  models  are  defined  to  provide  insight  into  and  to 
provide  the  ability  to  predict  critical  process  and  product  characteristics 
that  are  relevant  to  business  value. 

The  results  of  the  acquirer’s  process  performance  models  are  shared 
with  the  suppliers  so  that  they  can  ensure  synchronized  delivery  of 
products  and  services,  [acq] 


Examples  of  areas  of  concern  to  projects  in  which  models  may  be  useful  include  the 
following: 

•  Schedule  and  cost 

•  Reliability 

•  Defect  identification  and  removal  rates 

•  Defect  removal  effectiveness 

•  Latent  defect  estimation 

•  Response  time 

•  Project  progress 

•  Combinations  of  these  areas 
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Examples  of  process  performance  models  include  the  following:  [acqj 

•  System  dynamics  models 

•  Reliability  growth  models 

•  Complexity  models 

•  Supply  chain  models 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 

information  about  the  use  of  process  performance  models. 

Typical  Acquirer  Work  Products 

1 .  Process  performance  models 

Typical  Supplier  Deliverables 

1.  Supplier’s  process  performance  models  [acq] 

Subpractices 

1.  Establish  the  process  performance  models  based  on  the 
organization’s  set  of  standard  processes  and  the  organization’s 
process  performance  baselines. 

2.  Calibrate  the  process  performance  models  based  on  the 
organization’s  past  results  and  current  needs. 

3.  Review  the  process  performance  models  and  get  agreement  with 
relevant  stakeholders. 

4.  Support  the  projects’  use  of  the  process  performance  models. 

5.  Revise  the  process  performance  models  as  necessary. 


:  Examples  of  when  the  process  performance  models  may  need  to  be  revised 
:  include  the  following:  [acqj 

|  •  When  the  processes  change 
:  •  When  the  organization’s  results  change 
:  •  When  the  organization’s  needs  change 

i  •  When  supplier’s  processes  that  directly  interface  with  acquirer’s  processes 
j  change 

:  •  When  suppliers  change 
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ORGANIZATIONAL  TRAINING 


A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Training  (OT)  is  to  develop  the  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently. 


Introductory  Notes 


Organizational  Training  includes  training  to  support  the  organization’s 
strategic  business  objectives  and  to  meet  the  tactical  training  needs  that 
are  common  across  projects  and  support  groups.  Specific  training 
needs  identified  by  individual  projects  and  support  groups  are  handled 
at  the  project  and  support  group  level  and  are  outside  the  scope  of 
Organizational  Training.  Project  and  support  groups  are  responsible  for 
identifying  and  addressing  their  specific  training  needs. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects. 

An  organizational  training  program  involves  the  following: 

•  Identifying  the  training  needed  by  the  organization 

•  Obtaining  and  providing  training  to  address  those  needs 

•  Establishing  and  maintaining  training  capability 

•  Establishing  and  maintaining  training  records 

•  Assessing  training  effectiveness 

Effective  training  requires  assessment  of  needs,  planning,  instructional 
design,  and  appropriate  training  media  (e.g.,  workbooks,  computer 
software),  as  well  as  a  repository  of  training  process  data.  As  an 
organizational  process,  the  main  components  of  training  include  a 
managed  training  development  program,  documented  plans,  personnel 
with  appropriate  mastery  of  specific  disciplines  and  other  areas  of 
knowledge,  and  mechanisms  for  measuring  the  effectiveness  of  the 
training  program. 

The  identification  of  process  training  needs  is  primarily  based  on  the 
skills  that  are  required  to  perform  the  organization’s  set  of  standard 
processes. 
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Identification  of  training  needs  may  also  address  some  training  needs  of 
suppliers,  especially  in  those  process  elements  which  define  interfaces 
with  and  expectations  for  suppliers,  iacq] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  set  of  standard  processes. 

Certain  skills  may  be  effectively  and  efficiently  imparted  through 
vehicles  other  than  in-class  training  experiences  (e.g.,  informal 
mentoring).  Other  skills  require  more  formalized  training  vehicles,  such 
as  in  a  classroom,  by  Web-based  training,  through  guided  self-study,  or 
via  a  formalized  on-the-job  training  program.  The  formal  or  informal 
training  vehicles  employed  for  each  situation  should  be  based  on  an 
assessment  of  the  need  for  training  and  the  performance  gap  to  be 
addressed.  The  term  “training”  used  throughout  this  process  area  is 
used  broadly  to  include  all  of  these  learning  options. 

Success  in  training  can  be  measured  in  terms  of  the  availability  of 
opportunities  to  acquire  the  skills  and  knowledge  needed  to  perform 
new  and  ongoing  enterprise  activities. 

Skills  and  knowledge  may  be  technical,  organizational,  or  contextual. 
Technical  skills  pertain  to  the  ability  to  use  the  equipment,  tools, 
materials,  data,  and  processes  required  by  a  project  or  a  process. 
Organizational  skills  pertain  to  behavior  within  and  according  to  the 
employee’s  organization  structure,  role  and  responsibilities,  and  general 
operating  principles  and  methods.  Contextual  skills  are  the  self¬ 
management,  communication,  and  interpersonal  abilities  needed  to 
successfully  perform  in  the  organizational  and  social  context  of  the 
project  and  support  groups. 

The  phrase  “project  and  support  groups”  is  used  frequently  in  the  text  of 
the  process  area  description  to  indicate  an  organization-level 
perspective. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  process  assets. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  determining  training  approaches. 
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Specific  Goal  and  Practice  Summary 

SG  1  Establish  an  Organizational  Training  Capability 
SP  1 . 1  Establish  the  Strategic  T raining  Needs 

SP  1 .2  Determine  Which  T raining  Needs  Are  the 
Responsibility  of  the  Organization 
SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 
SP  1.4  Establish  Training  Capability 

SG  2  Provide  Necessary  Training 
SP2.1  Deliver  Training 

SP  2.2  Establish  Training  Records 

SP  2.3  Assess  Training  Effectiveness 


Specific  Practices  by  Goal 


SG  1  Establish  an  Organizational  Training  Capability 

A  training  capability  that  supports  the  organization's  management  and 
technical  roles  is  established  and  maintained. 

The  organization  identifies  the  training  required  to  develop  the  skills  and 
the  knowledge  necessary  to  perform  enterprise  activities.  Once  the 
needs  are  identified,  a  training  program  addressing  those  needs  is 
developed. 

SP  1.1  Establish  the  Strategic  Training  Needs 

Establish  and  maintain  the  strategic  training  needs  of  the 
organization. 


Strategic  training  needs  address  long-term  objectives  to  build  a 
capability  by  filling  significant  knowledge  gaps,  introducing  new 
technologies,  or  implementing  major  changes  in  behavior.  Strategic 
planning  typically  looks  two  to  five  years  into  the  future. 


Examples  of  sources  of  strategic  training  needs  include  the  following:  [acq] 

•  Organization’s  standard  processes 

•  Organization’s  strategic  business  plan 

•  Organization’s  process  improvement  plan 

•  Enterprise-level  initiatives 

•  Skill  assessments 

•  Risk  analyses 

•  Acquisition  and  supplier  management 


Typical  Acquirer  Work  Products 
1.  Training  needs 
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2.  Assessment  analysis 
Subpractices 

1 .  Analyze  the  organization’s  strategic  business  objectives  and 
process  improvement  plan  to  identify  potential  future  training 
needs. 

2.  Document  the  strategic  training  needs  of  the  organization. 


Examples  of  categories  of  training  needs  include  (but  are  not  limited  to)  the 
following:  [acq] 

•  Process  analysis  and  documentation 

•  Engineering  (e.g.,  requirements  analysis,  design,  testing,  configuration 
management,  and  quality  assurance) 

•  Selection  and  management  of  suppliers 

•  Management  (e.g.,  estimating,  tracking,  and  risk  management) 

•  Disaster  recovery  and  continuity  of  operations 

•  Acquisition  management  (e.g.,  solicitation,  supplier  selection,  supplier 
management) 

•  Communication  and  negotiation  skills 


3.  Determine  the  roles  and  skills  needed  to  perform  the  organization’s 
set  of  standard  processes. 

Roles  may  include  project/program  manager,  architects,  business  process 
analysts  and  suppliers,  especially  in  process  elements  that  identify  interfaces  with 
and  expectations  from  suppliers,  [acqi 

4.  Document  the  training  needed  to  perform  the  roles  in  the 
organization’s  set  of  standard  processes. 

5.  Document  the  training  needed  to  maintain  the  safe,  secure  and 
continued  operation  of  the  business. 

6.  Revise  the  organization’s  strategic  needs  and  required  training  as 
necessary. 

SP  1.2  Determine  Which  Training  Needs  Are  the  Responsibility  of  the 
Organization 

Determine  which  training  needs  are  the  responsibility  of  the 
organization  and  which  will  be  left  to  the  individual  project  or 
support  group. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
project-  and  support-group-specific  plans  for  training. 
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In  addition  to  strategic  training  needs,  organizational  training  addresses 
training  requirements  that  are  common  across  projects  and  support 
groups.  Projects  and  support  groups  have  the  primary  responsibility  for 
identifying  and  addressing  their  specific  training  needs.  The 
organization’s  training  staff  is  only  responsible  for  addressing  common 
cross-project  and  support  group  training  needs,  e.g.,  training  in  work 
environments  common  to  multiple  projects.  In  some  cases,  however, 
the  organization’s  training  staff  may  address  additional  training  needs  of 
projects  and  support  groups,  as  negotiated  with  them,  within  the  context 
of  the  training  resources  available  and  the  organization’s  training 
priorities. 

Typical  Acquirer  Work  Products 

1 .  Common  project  and  support  group  training  needs 

2.  Training  commitments 

Subpractices 

1 .  Analyze  the  training  needs  identified  by  the  various  projects  and 
support  groups. 

Analysis  of  project  and  support  group  needs  is  intended  to  identify  common 
training  needs  that  can  be  most  efficiently  addressed  organization-wide.  These 
needs-analysis  activities  are  used  to  anticipate  future  training  needs  that  are  first 
visible  at  the  project  and  support  group  level,  [acq] 

2.  Negotiate  with  the  various  projects  and  support  groups  on  how 
their  specific  training  needs  will  be  satisfied. 

The  support  provided  by  the  organization’s  training  staff  depends  on  the  training 
resources  available  and  the  organization’s  training  priorities,  [acq] 


Examples  of  training  appropriately  performed  by  the  project  or  support  group 
include  the  following:  [acq] 

•  Training  in  the  application  or  service  domain  of  the  project 

•  Training  in  the  unique  tools  and  methods  used  by  the  project  or  support  group 

•  Training  in  safety,  security,  and  human  factors 


3.  Document  the  commitments  for  providing  training  support  to  the 
projects  and  support  groups. 

SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 

Establish  and  maintain  an  organizational  training  tactical  plan. 
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The  organizational  training  tactical  plan  is  the  plan  to  deliver  the  training 
that  is  the  responsibility  of  the  organization  and  is  necessary  for 
individuals  to  perform  their  roles  effectively.  This  plan  addresses  the 
near-term  execution  of  training  and  is  adjusted  periodically  in  response 
to  changes  (e.g.,  in  needs  or  resources)  and  to  evaluations  of 
effectiveness. 

Typical  Acquirer  Work  Products 

1 .  Organizational  training  tactical  plan 

Subpractices 

1.  Establish  plan  content. 

Organizational  training  tactical  plans  typically  contain  the  following:  [acqi 

•  Training  needs 

•  Training  topics 

•  Schedules  based  on  training  activities  and  their  dependencies 

•  Methods  used  for  training 

•  Requirements  and  quality  standards  for  training  materials 

•  Training  tasks,  roles,  and  responsibilities 

•  Required  resources  including  tools,  facilities,  environments,  staffing,  and  skills  and 
knowledge 

2.  Establish  commitments  to  the  plan. 

Documented  commitments  by  those  responsible  for  implementing  and  supporting 
the  plan  are  essential  for  the  plan  to  be  effective,  [acq] 

3.  Revise  plan  and  commitments  as  necessary. 


SP  1.4  Establish  Training  Capability 

Establish  and  maintain  training  capability  to  address 
organizational  training  needs. 


Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  selecting  training  approaches  and 
developing  training  materials. 

Typical  Acquirer  Work  Products 

1.  Training  materials  and  supporting  artifacts 

Subpractices 

1 .  Select  the  appropriate  approaches  to  satisfy  specific  organizational 
training  needs. 
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Many  factors  may  affect  the  selection  of  training  approaches,  including  audience- 
specific  knowledge,  costs  and  schedule,  work  environment,  and  so  on.  Selection 
of  an  approach  requires  consideration  of  the  means  to  provide  skills  and 
knowledge  in  the  most  effective  way  possible  given  the  constraints,  [acq] 

;  Examples  of  training  approaches  include  the  following:  [acq] 

;  •  Classroom  training 
|  •  Computer-aided  instruction 
:  •  Guided  self-study 

i  •  Formal  apprenticeship  and  mentoring  programs 
j  •  Facilitated  videos 
i  •  Chalk  talks 
:  •  Brown-bag  lunch  seminars 

•  Structured  on-the-job  training 

2.  Determine  whether  to  develop  training  materials  internally  or 
acquire  them  externally. 

Determine  the  costs  and  benefits  of  internal  training  development  or  of  obtaining 
training  externally,  [acq] 

Example  criteria  that  can  be  used  to  determine  the  most  effective  mode  of 
:  knowledge  or  skill  acquisition  include  the  following:  [acq] 

:  •  Performance  objectives 
j  •  Time  available  to  prepare  for  project  execution 
i  •  Business  objectives 
i  •  Availability  of  in-house  expertise 

•  Availability  of  training  from  external  sources 

.  Examples  of  external  sources  of  training  include  the  following:  [acqj 

j  •  Customer-provided  training 
:  •  Commercially  available  training  courses 
i  •  Academic  programs 
j  •  Professional  conferences 

•  Seminars 

3.  Develop  or  obtain  training  materials. 

Training  may  be  provided  by  the  project,  by  support  groups,  by  the  organization, 
or  by  an  external  organization.  The  organization’s  training  staff  coordinates  the 
acquisition  and  delivery  of  training  regardless  of  its  source,  [acq] 
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Examples  of  training  materials  include  the  following:  [acq] 

•  Courses 

•  Computer-aided  instruction 

•  Videos 


4.  Develop  or  obtain  qualified  instructors. 

To  ensure  that  internally  provided  training  instructors  have  the  necessary 
knowledge  and  training  skills,  criteria  can  be  defined  to  identify,  develop,  and 
qualify  them.  In  the  case  of  externally  provided  training,  the  organization’s  training 
staff  can  investigate  how  the  training  provider  determines  which  instructors  will 
deliver  the  training.  This  can  also  be  a  factor  in  selecting  or  continuing  to  use  a 
specific  training  provider,  [acq] 

5.  Describe  the  training  in  the  organization's  training  curriculum. 

.  Examples  of  the  information  provided  in  the  training  descriptions  for  each  course 
:  include  the  following:  [acqj 

:•  Topics  covered  in  the  training 
:  •  Intended  audience 

i  •  Prerequisites  and  preparation  for  participating 
|  •  Training  objectives 
i  •  Length  of  the  training 
:  •  Lesson  plans 

j  •  Completion  criteria  for  the  course 
:  •  Criteria  for  granting  training  waivers 

6.  Revise  the  training  materials  and  supporting  artifacts  as  necessary. 


Examples  of  situations  in  which  the  training  materials  and  supporting  artifacts  may  ; 
need  to  be  revised  include  the  following:  [acq]  j 

•  Training  needs  change  (e.g.,  when  new  technology  associated  with  the  training  : 

topic  is  available)  : 

•  An  evaluation  of  the  training  identifies  the  need  for  change  (e.g.,  evaluations  of  : 
training  effectiveness  surveys,  training  program  performance  assessments,  or  : 
instructor  evaluation  forms) 


SG  2  Provide  Necessary  Training 

Training  necessary  for  individuals  to  perform  their  roles  effectively  is 
provided. 
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•  Background  of  the  target  population  of  training  participants 

•  Prerequisite  background  to  receive  training 

•  Skills  and  abilities  needed  by  people  to  perform  their  roles 

•  Need  for  cross-discipline  technical  management  training  for  all 
disciplines,  including  project  management 

•  Need  for  managers  to  have  training  in  appropriate  organizational 
processes 

•  Need  for  training  in  the  basic  principles  of  discipline-specific 
engineering  or  services  to  support  personnel  in  quality 
management,  configuration  management,  and  other  related  support 
functions 

•  Need  to  provide  competency  development  for  critical  functional 
areas 

•  Need  to  maintain  the  competencies  and  qualifications  of  personnel 
to  operate  and  maintain  work  environments  common  to  multiple 
projects 

SP  2.1  Deliver  Training 

Deliver  the  training  following  the  organizational  training  tactical 

plan. 


Typical  Acquirer  Work  Products 
1.  Delivered  training  course 

Subpractices 

1 .  Select  the  people  who  will  receive  the  training  necessary  to 
perform  their  roles  effectively. 

The  acquirer  must  include  supplier  representatives,  as  appropriate,  to  ensure 
selected  suppliers  can  effectively  interface  with  the  acquirer’s  processes,  [acqj 

Training  is  intended  to  impart  knowledge  and  skills  to  people  performing  various 
roles  within  the  organization.  Some  people  already  possess  the  knowledge  and 
skills  required  to  perform  well  in  their  designated  roles.  Training  can  be  waived  for 
these  people,  but  care  should  be  taken  that  training  waivers  are  not  abused,  [acq] 

2.  Schedule  the  training,  including  any  resources,  as  necessary  (e.g., 
facilities  and  instructors). 

Training  should  be  planned  and  scheduled.  Training  is  provided  that  has  a  direct 
bearing  on  the  expectations  of  work  performance.  Therefore,  optimal  training 
occurs  in  a  timely  manner  with  regard  to  imminent  job-performance  expectations. 
These  expectations  often  include  the  following:  [acq] 


Organizational  Training 


Training  in  the  use  of  specialized  tools 

Training  in  procedures  that  are  new  to  the  individual  who  will  perform  them 
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3.  Conduct  the  training. 

Experienced  instructors  should  perform  training.  When  possible,  training  is 
conducted  in  settings  that  closely  resemble  actual  performance  conditions  and 
includes  activities  to  simulate  actual  work  situations.  This  approach  includes 
integration  of  tools,  methods,  and  procedures  for  competency  development. 
Training  is  tied  to  work  responsibilities  so  that  on-the-job  activities  or  other  outside 
experiences  will  reinforce  the  training  within  a  reasonable  time  after  the  training. 

[ACQ] 

4.  T rack  the  delivery  of  training  against  the  plan. 


SP  2.2  Establish  Training  Records 

Establish  and  maintain  records  of  the  organizational  training. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
about  how  project  or  support  group  training  records  are  maintained. 

The  scope  of  this  practice  is  for  the  training  performed  at  the 
organizational  level.  Establishment  and  maintenance  of  training  records 
for  project-  or  support-group-sponsored  training  is  the  responsibility  of 
each  individual  project  or  support  group. 

Typical  Acquirer  Work  Products 

1.  Training  records 

2.  Training  updates  to  the  organizational  repository 

Typical  Supplier  Deliverables 

1.  Training  records,  if  appropriate  [acq] 

Subpractices 

1 .  Keep  records  of  all  students  who  successfully  complete  each 
training  course  or  other  approved  training  activity  as  well  as  those 
who  are  unsuccessful. 

2.  Keep  records  of  all  staff  who  have  been  waived  from  specific 
training. 

The  rationale  for  granting  a  waiver  should  be  documented,  and  both  the  manager 
responsible  and  the  manager  of  the  excepted  individual  should  approve  the 
waiver  for  organizational  training,  [acq] 

3.  Keep  records  of  all  students  who  successfully  complete  their 
designated  required  training. 

4.  Make  training  records  available  to  the  appropriate  people  for 
consideration  in  assignments. 
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Training  records  may  be  part  of  a  skills  matrix  developed  by  the  training 
organization  to  provide  a  summary  of  the  experience  and  education  of  people,  as 
well  as  training  sponsored  by  the  organization,  [acq] 


SP  2.3  Assess  Training  Effectiveness 

Assess  the  effectiveness  of  the  organization’s  training 
program. 

A  process  should  exist  to  determine  the  effectiveness  of  training  (i.e., 
how  well  the  training  is  meeting  the  organization’s  needs). 

Examples  of  methods  used  to  assess  training  effectiveness  include  the  following: 
j  •  Testing  in  the  training  context 
|  •  Post-training  surveys  of  training  participants 
;  •  Surveys  of  managers’  satisfaction  with  post-training  effects 
•  Assessment  mechanisms  embedded  in  courseware 


Measures  may  be  taken  to  assess  the  benefit  of  the  training  against 
both  the  project’s  and  organization’s  objectives.  Particular  attention 
should  be  paid  to  the  need  for  various  training  methods,  such  as 
training  teams  as  integral  work  units.  When  used,  performance 
objectives  should  be  shared  with  course  participants,  and  should  be 
unambiguous,  observable,  and  verifiable.  The  results  of  the  training¬ 
effectiveness  assessment  should  be  used  to  revise  training  materials  as 
described  in  the  Establish  Training  Capability  specific  practice. 

Typical  Acquirer  Work  Products 

1.  Training-effectiveness  surveys 

2.  Training  program  performance  assessments 

3.  Instructor  evaluation  forms 

4.  Training  examinations 

Subpractices 

1 .  Assess  in-progress  or  completed  projects  to  determine  whether 
staff  knowledge  is  adequate  for  performing  project  tasks. 

2.  Provide  a  mechanism  for  assessing  the  effectiveness  of  each 
training  course  with  respect  to  established  organizational,  project, 
or  individual  learning  (or  performance)  objectives. 

3.  Obtain  student  evaluations  of  how  well  training  activities  met  their 
needs. 


Organizational  Training 
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PROJECT  MONITORING  AND  CONTROL 

A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Monitoring  and  Control  (PMC)  is  to  provide  an 
understanding  of  the  project’s  progress  so  that  appropriate  corrective 
actions  can  be  taken  when  the  project’s  performance  deviates 
significantly  from  the  plan. 


Introductory  Notes 


A  project’s  documented  plan  is  the  basis  for  monitoring  activities, 
communicating  status,  and  taking  corrective  action.  Progress  is 
primarily  determined  by  comparing  actual  work  product  and  task 
attributes,  effort,  cost,  and  schedule  to  the  plan  at  prescribed 
milestones  or  control  levels  within  the  project  schedule  or  work 
breakdown  structure  (WBS).  Appropriate  visibility  enables  timely 
corrective  action  to  be  taken  when  performance  deviates  significantly 
from  the  plan.  A  deviation  is  significant  if,  when  left  unresolved,  it 
precludes  the  project  from  meeting  its  objectives. 

The  term  “project  plan”  is  used  throughout  these  practices  to  refer  to  the 
overall  plan  for  controlling  the  project. 

Monitoring  and  control  functions  are  directed  within  the  project  early  in 
the  process  as  the  project’s  planning  is  performed  and  the  acquisition 
strategy  is  defined.  As  the  acquisition  of  technology  solutions  unfolds, 
monitoring  and  controlling  are  essential  to  ensuring  that  appropriate 
resources  are  being  applied  and  that  the  acquirer’s  activities  are 
progressing  according  to  plan,  [acq] 

When  actual  status  deviates  significantly  from  the  expected  values, 
corrective  actions  are  taken  as  appropriate.  These  actions  may  require 
replanning,  which  may  include  revising  the  original  plan,  establishing 
new  agreements,  or  including  additional  mitigation  activities  within  the 
current  plan. 

If  a  corrective  action  is  required  to  resolve  variances  from  project  plans, 
these  actions  should  be  defined  and  tracked  to  closure,  [acq] 
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After  a  supplier  is  selected  and  a  supplier  agreement  is  established,  the 
role  of  monitoring  and  control  becomes  twofold,  concerned  with 
continuing  to  monitor  and  control  acquirer  activities  and  work  products 
while  also  monitoring  and  controlling  the  progress  and  performance  of 
the  supplier’s  execution  under  the  supplier  agreement  and  the 
supplier’s  project  plans,  [acq] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  project  plan,  including  how  it  specifies  the  appropriate  level  of 
project  monitoring,  the  measures  used  to  monitor  progress,  and  known 
risks. 

Refer  to  the  Measurement  and  Analysis  process  area  for  information 
about  the  process  of  measuring,  analyzing,  and  recording  information. 

Refer  to  the  Acquisition  Management  process  area  for  information 
about  the  process  resolving  issues  or  making  changes  to  the  supplier 
agreement,  [acq] 


Project  Monitoring  and  Control 
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Specific  Goal  and  Practice  Summary 

SG  1  Monitor  Project  Against  Plan 

SP  1.1  Monitor  Project  Planning  Parameters 

SP1.2  Monitor  Commitments 

SP  1 .3  Monitor  Project  Risks 

SP  1 .4  Monitor  Data  Management 

SP  1 .5  Monitor  Stakeholder  Involvement 

SP  1 .6  Conduct  Progress  Reviews 

SP  1.7  Conduct  Milestone  Reviews 

SP  1 .8  Monitor  T ransition  to  Operations  and  Support 

SG  2  Manage  Corrective  Action  to  Closure 
SP  2.1  Analyze  Issues 

SP  2.2  Take  Corrective  Action 

SP  2.3  Manage  Corrective  Action 


Specific  Practices  by  Goal 


SG  1  Monitor  Project  Against  Plan 

Actual  performance  and  progress  of  the  project  are  monitored  against  the 
project  plan. 

Monitoring  of  the  acquirer’s  progress  and  performance  begins  as  soon 
as  a  plan  is  established.  The  acquirer  is  responsible  for  monitoring  the 
progress  and  output  of  the  project.  After  a  supplier  is  selected  and  a 
supplier  agreement  put  in  place,  the  acquirer’s  monitoring  and  control 
activities  extend  to  the  supplier  and  its  activities.  The  acquirer  monitors 
the  progress  of  the  supplier,  including  achievement  of  service  levels 
established  in  the  supplier  agreement,  using  the  supplier’s 
measurement  data  about  the  progress  and  output  produced  by  the 
supplier,  [acq] 


SP  1.1  Monitor  Project  Planning  Parameters 

Monitor  the  actual  values  of  the  project  planning  parameters 
against  the  project  plan. 


Project  planning  parameters  constitute  typical  indicators  of  project 
progress  and  performance  and  include  attributes  of  work  products  and 
tasks,  cost,  effort,  and  schedule.  Attributes  of  the  work  products  and 
tasks  include  such  items  as  size,  complexity,  weight,  form,  fit,  or 
function. 

Monitoring  typically  involves  measuring  the  actual  values  of  project 
planning  parameters,  comparing  actual  values  to  the  estimates  in  the 
plan,  and  identifying  significant  deviations.  Recording  actual  values  of 
the  project  planning  parameters  includes  recording  associated 
contextual  information  to  help  understand  the  measures.  An  analysis  of 
the  impact  that  significant  deviations  have  on  determining  what 
corrective  actions  to  take  is  handled  in  the  second  specific  goal  and  its 
specific  practices  in  this  process  area. 
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Typical  Acquirer  Work  Products 

1 .  Records  of  project  performance 

2.  Records  of  significant  deviations 

Typical  Supplier  Deliverables 

1 .  Supplier  progress  reports  and  performance  measures  [acq] 

2.  Records  of  significant  deviations  [acq] 

Subpractices 

1 .  Monitor  progress  against  the  schedule. 

Progress  monitoring  typically  includes  the  following:  [acq] 

•  Periodically  measuring  the  actual  completion  of  activities  and  milestones 

•  Comparing  actual  completion  of  activities  and  milestones  against  the  schedule 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  schedule  estimates  in  the  project  plan 

2.  Monitor  the  project's  cost  and  expended  effort. 

Effort  and  cost  monitoring  typically  includes  the  following:  [acq] 

•  Periodically  measuring  the  actual  effort  and  cost  expended  and  staff  assigned 

•  Comparing  actual  effort,  costs,  staffing,  and  training  to  the  estimates  and  budgets 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  budgets  in  the  project  plan 

3.  Monitor  the  attributes  of  the  work  products  and  tasks. 

Refer  to  the  Project  Planning  process  area  for  information  about 
the  attributes  of  work  products  and  tasks. 

Monitoring  the  attributes  of  the  work  products  and  tasks  typically  includes  the 
following:  [acqi 

•  Periodically  measuring  the  actual  attributes  of  the  work  products  and  tasks,  such 
as  size  or  complexity  (and  the  changes  to  the  attributes) 

•  Comparing  the  actual  attributes  of  the  work  products  and  tasks  (and  the  changes 
to  the  attributes)  to  the  estimates  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  estimates  in  the  project  plan 

In  addition  to  monitoring  the  attributes  of  its  work  products,  the  acquirer  monitors 
the  attributes  of  supplier  deliverables  through  acceptance  criteria  and  through 
analyzing  the  supplier’s  peer  review  results,  [acqi 

4.  Monitor  resources  provided  and  used. 


Project  Monitoring  and  Control 


Refer  to  the  Project  Planning  process  area  for  information  about 
planned  resources. 
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This  includes  monitoring  the  availability  of  resources  provided  by  the  supplier  for 
the  project,  [acqi 

5.  Monitor  the  knowledge  and  skills  of  project  personnel. 

Refer  to  the  Project  Planning  process  area  for  information  about 
planning  for  knowledge  and  skills  needed  to  perform  the  project. 

Monitoring  the  knowledge  and  skills  of  the  project  personnel  typically  includes  the 
following:  [acqi 

•  Periodically  measuring  the  acquisition  of  knowledge  and  skills  by  project 
personnel 

•  Comparing  actual  training  obtained  to  that  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  estimates  in  the  project  plan 

This  includes  monitoring  the  skills  and  knowledge  of  the  supplier  personnel 
provided  for  the  project,  [acqi 

6.  Document  the  significant  deviations  in  the  project  planning  parameters. 

Document  the  significant  deviations  that  apply  either  to  the  acquirer’s  project 
execution  or  to  the  supplier’s  deviations  from  the  project  plan,  [acqi 


SP  1.2  Monitor  Commitments 

Monitor  commitments  against  those  identified  in  the  project 
plan. 


Commitments  for  resources  that  will  result  in  expenditures  (e.g.,  issued 
purchase  orders  and  completed  supplier  deliverables  that  have  been 
accepted)  are  tracked  when  incurred,  even  prior  to  formal  payment,  to 
ensure  that  future  financial  and  legal  obligations  are  accounted  for  as 
soon  as  they  are  incurred,  [acqi 

Supplier  commitments  for  the  project  are  also  monitored  by  the  acquirer 
through  these  practices,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Records  of  commitment  reviews 

Subpractices 

1 .  Regularly  review  commitments  (both  external  and  internal). 

2.  Identify  commitments  that  have  not  been  satisfied  or  that  are  at 
significant  risk  of  not  being  satisfied. 

3.  Document  the  results  of  the  commitment  reviews. 
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SP  1.3  Monitor  Project  Risks 

Monitor  risks  against  those  identified  in  the  project  plan. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  project  risks. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities. 

The  acquirer  monitors  overall  project  risk.  Many  risks  are  the  sole 
responsibility  of  the  acquirer  and  may  include  sensitive  information  that 
should  not  be  shared  with  the  supplier  (e.g.,  source  selection  sensitive, 
re-competition,  internal  staffing,  or  other  risks),  [acq] 

There  can  also  be  risks  that  require  careful  coordination  with  suppliers 
and  establishing  appropriate  escalation  of  risks  and  risk  status  (e.g., 
feasibility  of  the  technology  to  meet  end  user  performance 
requirements).  Shared  risks  may  affect  the  mitigation  approaches  and 
result  in  jointly-planned  mitigations,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Records  of  project  risk  monitoring 

Typical  Supplier  Deliverables 

1 .  Records  of  supplier  risk  monitoring  [acq] 

Subpractices 

1 .  Periodically  review  the  documentation  of  the  risks  in  the  context  of 
the  project’s  current  status  and  circumstances. 

2.  Revise  the  documentation  of  the  risks,  as  additional  information 
becomes  available,  to  incorporate  changes. 

3.  Communicate  risk  status  to  relevant  stakeholders. 


Examples  of  risk  status  include  the  following:  [acqi 

•  A  change  in  the  probability  that  the  risk  occurs 

•  A  change  in  risk  priority 


SP  1.4  Monitor  Data  Management 

Monitor  the  management  of  project  data  against  the  project 
plan. 


Refer  to  the  Plan  for  Data  Management  specific  practice  in  the  Project 
Planning  process  area  for  more  information  about  identifying  the  types 
of  data  that  should  be  managed  and  how  to  plan  for  their  management. 


Project  Monitoring  and  Control 
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Once  the  plans  for  the  management  of  project  data  are  made,  the 
management  of  that  data  must  be  monitored  to  ensure  that  those  plans 
are  accomplished. 

Typical  Acquirer  Work  Products 

1 .  Records  of  data  management 

Typical  Supplier  Deliverables 

1 .  Records  of  supplier  data  management  [acq] 

Subpractices 

1 .  Periodically  review  data  management  activities  against  their 
description  in  the  project  plan. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

3.  Document  the  results  of  data  management  activity  reviews. 


SP  1.5  Monitor  Stakeholder  Involvement 

Monitor  stakeholder  involvement  against  the  project  plan. 


Refer  to  the  Plan  Stakeholder  Involvement  specific  practice  in  the 
Project  Planning  process  area  for  more  information  about  identifying 
relevant  stakeholders  and  planning  the  appropriate  involvement  with 
them. 

Once  the  stakeholders  are  identified  and  the  extent  of  their  involvement 
within  the  project  is  specified  in  project  planning,  that  involvement  must 
be  monitored  to  ensure  that  the  appropriate  interactions  are  occurring. 

The  supplier’s  role  as  a  stakeholder  is  specified  in  the  supplier 
agreement,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Records  of  stakeholder  involvement 

Typical  Supplier  Deliverables 

1 .  Records  of  supplier  involvement  [acq] 

Subpractices 

1 .  Periodically  review  the  status  of  stakeholder  involvement. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

3.  Document  the  results  of  the  stakeholder  involvement  status 
reviews. 
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SP  1.6  Conduct  Progress  Reviews 

Periodically  review  the  project's  progress,  performance,  and 
issues. 


Progress  reviews  are  reviews  on  the  project  to  keep  stakeholders 
informed.  These  project  reviews  can  be  informal  reviews  and  may  not 
be  specified  explicitly  in  the  project  plans. 


Examples  of  these  reviews  include  the  following:  [acq] 

•  Reviews  with  staff 

•  Reviews  with  project  engineers  and  support 

•  Reviews  with  management 

•  Reviews  with  suppliers 


Typical  Acquirer  Work  Products 

1 .  Documented  project  review  results 

Typical  Supplier  Deliverables 

1 .  Supplier  progress  reports  and  performance  measures  [acq] 

2.  Supplier  review  materials  and  reports  [acq] 

3.  Documentation  of  product  and  document  deliveries  [acq] 

Subpractices 

1 .  Regularly  communicate  status  on  assigned  activities  and  work 
products  to  relevant  stakeholders. 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  reviews  as  appropriate. 

[ACQ] 

2.  Review  the  results  of  collecting  and  analyzing  measures  for 
controlling  the  project. 
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Examples  of  classes  of  commonly  used  acquirer  measures  include  the  following: 

[ACQ] 

•  Requirements  Volatility 

•  Return  on  Investment 

•  Cost  Performance  Index 

•  Number  of  Defects  Per  Phase  and/or  by  severity  of  defects 

•  Schedule  Performance  Index 

•  Customer  Satisfaction  Trends 

•  Supplier  Performance  and  Relationship  Trends 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  process  for  measuring  and  analyzing  project 
performance  data. 

3.  Monitor  supplier  progress  and  performance  (schedule,  effort,  cost, 
and  technical  performance)  as  defined  in  the  supplier  agreement. 

[ACQ] 

4.  Conduct  progress  reviews  with  the  supplier  as  specified  in  the 
supplier  agreement,  [acq] 

Technical  and  management  progress  reviews  may  be  coordinated  and  held 
jointly.  Management  reviews  typically  include  acquirer  and  supplier  measures, 
critical  dependencies,  and  project  risks  and  issues.  Technical  reviews  are  an 
important  oversight  tool  that  the  acquirer  can  use  to  review  and  evaluate  the  state 
of  the  product  and  of  the  project,  re-directing  activity  after  the  review  if  found 
necessary,  [acqj 

Technical  reviews  typically  include  the  following:  [acqi 

•  Reviewing  the  supplier’s  technical  activities  and  verifying  that  the  supplier’s 
interpretation  and  implementation  of  the  requirements  are  consistent  with  the 
customer’s  interpretation 

•  Ensuring  that  technical  commitments  are  being  met  and  that  technical  issues  are 
communicated  and  resolved  in  a  timely  manner 

•  Obtaining  technical  information  about  the  supplier’s  products 

•  Providing  appropriate  technical  information  (e.g.,  design  constraints)  and  support 
to  the  supplier 

5.  Identify  and  document  significant  issues  and  deviations  from  the 
plan. 

This  includes  identifying  and  documenting  both  acquirer  and  supplier  issues  and 
deviations,  [acqj 

6.  Document  change  requests  and  problems  identified  in  any  of  the 
work  products  and  processes. 
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Refer  to  the  Configuration  Management  process  area  for  more 
information  about  how  changes  are  managed. 

7.  Document  the  results  of  the  reviews. 

Use  the  results  of  reviews  to  improve  the  supplier’s  performance  and  to  establish 
and  nurture  long-term  relationships  with  preferred  suppliers,  [acq] 

8.  Track  change  requests  and  problem  reports  to  closure. 


SP  1.7  Conduct  Milestone  Reviews 

Review  the  accomplishments  and  results  of  the  project  at 
selected  project  milestones. 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
milestone  planning. 

Refer  to  the  Measurement  and  Analysis  process  area  for  information 
about  the  process  of  measuring,  analyzing,  and  recording  project 
performance  data,  [acq] 

Milestone  reviews  are  planned  during  project  planning  and  are  typically 
formal  reviews. 

Typical  Acquirer  Work  Products 

1.  Documented  milestone  review  results 

Typical  Supplier  Deliverables 

1.  Documented  measurement  results  [acq] 

2.  Measurement  analysis  reports  [acq] 

Subpractices 

1 .  Conduct  reviews  at  meaningful  points  in  the  project’s  schedule, 
such  as  the  completion  of  selected  stages,  with  relevant 
stakeholders. 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  milestone  reviews  as 
appropriate,  [acq] 

Conduct  milestone  reviews  with  the  supplier  as  specified  in  the  supplier 
agreement,  [acq] 

2.  Review  the  commitments,  plan,  status,  and  risks  of  the  project. 

3.  Identify  and  document  significant  issues  and  their  impacts. 

4.  Document  the  results  of  the  review,  action  items,  and  decisions. 

5.  Track  action  items  to  closure. 
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SP  1.8  Monitor  Transition  to  Operations  and  Support  [acq] 

Monitor  the  transition  to  operations  and  support  [acqj 


Refer  to  the  Acquisition  Management  process  area  for  more  information 
on  escalation  of  agreement  related  issues,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Records  of  transition  to  support  reviews  [acq] 

2.  Transition  Analysis  Report  [acq] 

Typical  Supplier  Deliverables 

1.  Training  materials  and  supporting  artifacts  [acqj 

2.  Site  Readiness  Report  [acq] 

3.  Verification  Reports  [acqj 

4.  Training  records  [acq] 

5.  Operational  readiness  reports  [acq] 

6.  Test  results  [acq] 

7.  Pilot  results  [acq] 

Subpractices 

1 .  Monitor  the  organization’s  capability  and  facilities  designated  to 
receive,  store,  use,  and  maintain  the  acquired  products  [acq] 

The  acquirer  makes  adequate  provisions  through  the  supplier  agreement  or  in- 
house  operations  and  support  organizations  to  operate  the  acquired  product. 
Typically,  the  acquirer  uses  the  verification  practices  to  confirm  that  the 
organization,  the  physical  environment,  and  the  operations  and  support  resources 
are  equipped  to  execute  the  operations  and  support  activities,  [acq] 

The  acquirer  also  reviews  operations  and  support  organizations  designated  to 
take  responsibility  for  operation  of  the  product  and  to  ensure  that  the  resources 
identified,  and  budgeted  are  available  when  needed.  The  designated  operations 
and  support  organizations  demonstrate  their  readiness  (capability  and  capacity)  to 
accept  responsibility  for  the  product  and  to  ensure  uninterrupted  support.  Typically 
a  demonstration  involves  execution  of  all  the  activities  of  operations  (e.g.,  a  pilot). 

[ACQ] 

2.  Monitor  delivery  of  training  for  those  involved  in  receiving,  storing, 
using,  and  maintaining  the  acquired  products,  [acq] 


250 


Project  Monitoring  and  Control 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Typically  the  supplier  develops  training  resources  for  the  product.  The  training 
materials  and  resources  are  specified  in  the  supplier  agreement  to  meet  the 
needs  of  various  audiences  (e.g.,  operations  staff,  support  staff,  end  users).  The 
acquirer  verifies  that  the  training  is  provided  at  the  appropriate  time  to  the 
appropriate  audience  and  determines  whether  the  training  capability  provided  is 
adequate,  [acqi 

3.  Review  pilot  results,  if  any,  and  operational  readiness  reports  for 
the  acquired  product  [acq] 

Determine  readiness  of  the  product  and  the  involved  stakeholders  such  as  the 
operations  and  support  organizations  for  the  transition  of  responsibility.  The 
acquirer  typically  uses  transition  readiness  criteria  and  the  verification  and 
validation  practices  to  determine  if  the  supplier’s  delivered  products  meet 
specified  requirements.  The  criteria  also  address  the  readiness  of  the  product  for 
maintenance  over  the  intended  product  life  cycle,  [acqi 

4.  Review  and  analyze  the  results  of  transition  activities,  [acq] 


Example  reports  and  logs  used  by  the  acquirer  include  the  following:  [acqi 

•  Transition  activity  reports  including  quality  measures  collected  during  the  pilot  and 
the  warranty  period 

•  Problem  tracking  reports,  detailing  resolution  time,  escalation,  root  cause  analysis 

•  Change  management  reports 

•  Configuration  management  records 

•  Operation  logs  to  determine  that  sufficient  information  is  stored  to  support 
reconstruction 

•  Security  reports 

•  Actual  operations  and  support  costs  compared  to  estimates 


SG  2  Manage  Corrective  Action  to  Closure 

Corrective  actions  are  managed  to  closure  when  the  project's  performance 
or  results  deviate  significantly  from  the  plan. 

When  the  acquirer  identifies,  for  example,  through  its  monitoring  of 
measurement  data  that  supplier  progress  does  not  appear  to  be 
sufficient  to  meet  a  service  level  defined  in  the  supplier  agreement,  then 
the  acquirer  initiates  and  manages  corrective  action  through  the 
supplier,  [acq] 

If  the  supplier  does  not  comply  appropriately  with  the  acquirer's  initiation 
of  corrective  action,  the  acquirer  escalates  and  handles  this  as  a 
supplier  agreement  issue  or  dispute,  [acq] 

Refer  to  the  Acquisition  Management  process  area  for  more  information 
on  escalation  of  agreement  related  issues,  [acq] 
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SP  2.1  Analyze  Issues 

Collect  and  analyze  the  issues  and  determine  the  corrective 
actions  necessary  to  address  the  issues. 


Many  issues  and  corrective  actions  are  the  sole  responsibility  of  the 
acquirer  and  may  include  sensitive  information  that  should  not  be 
shared  with  the  supplier  (e.g.,  source  selection  sensitive,  re¬ 
competition,  and  internal  staffing),  [acq] 

Typical  Acquirer  Work  Products 

1 .  List  of  issues  needing  corrective  actions 

Typical  Supplier  Deliverables 

1 .  List  of  supplier  issues  needing  corrective  action  by  the  acquirer  [acq] 
Subpractices 

1.  Gather  issues  for  analysis. 

Issues  are  collected  from  reviews  and  the  execution  of  other  processes,  [acq] 

:  Examples  of  issues  to  be  gathered  include:  [acq] 

i  •  Issues  discovered  through  performing  verification  and  validation  activities 

|  •  Significant  deviations  in  the  project  planning  parameters  from  the  estimates  in  the 
j  project  plan 

i  •  Commitments  (either  internal  or  external)  that  have  not  been  satisfied 
:  •  Significant  changes  in  risk  status 
i  •  Data  access,  collection,  privacy,  or  security  issues 
•  Stakeholder  representation  or  involvement  issues 

2.  Analyze  issues  to  determine  need  for  corrective  action. 

Refer  to  the  Project  Planning  process  area  for  information  about 
corrective  action  criteria. 

Corrective  action  is  required  when  the  issue,  if  left  unresolved,  may  prevent  the 
project  from  meeting  its  objectives,  [acqj 


SP  2.2  Take  Corrective  Action 

Take  corrective  action  on  identified  issues. 


Corrective  action  is  taken  for  both  acquirer  deviations  and  when 
supplier  execution  does  not  align  with  project  planning  (e.g.,  milestones 
and  work  product  date  slippages).  Some  corrective  actions  may  be 
assigned  to  a  supplier.  Significant  supplier  issues  and  disputes  can  be 
escalated  and  addressed  through  the  Acquisition  Management 
practices,  [acq] 
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The  acquirer  oversees  corrective  actions  for  the  supplier  as  appropriate. 

[ACQ] 

Refer  to  the  Acquisition  Management  process  area  for  more  information 
about  how  supplier  issues  may  be  escalated  and  addressed,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Corrective  action  plan 

Typical  Supplier  Deliverables 

1 .  Corrective  action  plans  for  supplier  issues  [acqi 

Subpractices 

1 .  Determine  and  document  the  appropriate  actions  needed  to 
address  the  identified  issues. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  the  project  plan  when  replanning  is  needed. 

:  Examples  of  potential  actions  include  the  following:  [acqi 

i  •  Modifying  the  statement  of  work 
:  •  Modifying  requirements 
|  •  Revising  estimates  and  plans 
|  •  Renegotiating  commitments 
:  •  Adding  resources 
i  •  Changing  processes 
•  Revising  project  risks 

2.  Review  and  get  agreement  with  relevant  stakeholders  on  the 
actions  to  be  taken. 

3.  Negotiate  changes  to  internal  and  external  commitments. 

SP  2.3  Manage  Corrective  Action 

Manage  corrective  actions  to  closure. 


Typical  Acquirer  Work  Products 

1 .  Corrective  action  results 

Typical  Supplier  Deliverables 

1 .  Corrective  action  plans  for  supplier  issues  [acqi 

Subpractices 

1 .  Monitor  corrective  actions  for  completion. 
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2.  Analyze  results  of  corrective  actions  to  determine  the  effectiveness 
of  the  corrective  actions. 

3.  Determine  and  document  appropriate  actions  to  correct  deviations 
from  planned  results  for  corrective  actions. 

Lessons  learned  as  a  result  of  taking  corrective  action  can  be  inputs  to  planning 
and  risk  management  processes,  [acqj 
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PROJECT  PLANNING 


A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Planning  (PP)  is  to  establish  and  maintain  plans 
that  define  project  activities. 


Introductory  Notes 


The  Project  Planning  process  area  involves  the  following: 

•  Developing  the  project  plan 

•  Interacting  with  stakeholders  appropriately 

•  Getting  commitment  to  the  plan 

•  Maintaining  the  plan 

Planning  begins  with  requirements  that  define  the  product  and  project. 

Project  planning  is  based  on  the  acquisition  strategy  developed  by  the 
Solicitation  and  Supplier  Agreement  Development  process  area.  The 
acquisition  strategy  outlines  the  objectives  for  the  acquisition, 
constraints,  availability  of  assets  and  technologies,  consideration  of 
acquisition  methods,  potential  supplier  agreement  types  and  terms, 
accommodation  of  end  user  considerations,  considerations  of  risk,  and 
support  for  the  project  over  the  project  life  cycle,  [acq] 

Planning  includes  estimating  the  attributes  of  the  work  products  and 
tasks,  determining  the  resources  needed,  negotiating  commitments, 
producing  a  schedule,  and  identifying  and  analyzing  project  risks. 
Iterating  through  these  activities  may  be  necessary  to  establish  the 
project  plan.  The  project  plan  provides  the  basis  for  performing  and 
controlling  the  project’s  activities  that  address  the  commitments  with  the 
project’s  customer. 

Project  Planning  involves  development  and  maintenance  of  plans  for  all 
acquirer  processes  including  those  processes  required  for  an  effective 
acquirer-supplier  interaction.  Once  the  supplier  agreement  is  signed, 
and  schedule,  cost,  and  resources  from  the  supplier  are  established, 
the  acquirer’s  project  plan  takes  the  supplier  estimations  for  the  project 
into  account  at  an  appropriate  level  of  detail,  [acq] 
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Project  planning  includes  establishing  and  maintaining  a  plan  for  the 
orderly,  smooth  transition  of  the  acquired  product  from  a  supplier  to  its 
use  by  the  acquirer  or  its  customers.  In  addition,  if  an  existing  product  is 
to  be  replaced  as  part  of  the  acquisition,  the  acquirer  may  be  required 
to  consider  the  disposal  of  the  existing  product  as  part  of  the  planning 
for  acquiring  the  new  product.  Any  such  transition  activities  are  included 
in  the  project  plan,  and  provisions  for  accommodating  such  specialized 
requirements  are  also  included,  [acq] 

The  project  plan  will  usually  need  to  be  revised  as  the  project 
progresses  to  address  changes  in  requirements  and  commitments, 
inaccurate  estimates,  corrective  actions,  and  process  changes.  Specific 
practices  describing  both  planning  and  replanning  are  contained  in  this 
process  area. 

Changes  to  the  supplier  agreement  can  also  affect  the  project’s 
planning  estimates,  budget,  schedules,  risks,  project  work  tasks, 
commitments,  and  resources,  [acqj 

The  term  “project  plan”  is  used  throughout  the  generic  and  specific 
practices  in  this  process  area  to  refer  to  the  overall  plan  for  controlling 
the  project. 


Related  Process  Areas 


Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  developing  requirements,  [acqj 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements  needed  for  planning  and 
replanning. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  managing  risks. 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  transforming  requirements  into  solutions,  [acq] 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  developing  an  acquisition  strategy  and 
establishing  supplier  agreements,  [acqj 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  project  measurement  data  requirements. 

[ACQ] 
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Specific  Goal  and  Practice  Summary 

SG  1  Establish  Estimates 

SP  1 .1  Estimate  the  Scope  of  the  Project 
SP  1 .2  Establish  Estimates  of  Work  Product  and  Task 

Attributes 

SP  1 .3  Define  Project  Life  Cycle 
SP  1 .4  Determine  Estimates  of  Effort  and  Cost 
SG  2  Develop  a  Project  Plan 

SP  2.1  Establish  the  Budget  and  Schedule 
SP  2.2  Identify  Project  Risks 

SP  2.3  Plan  for  Data  Management 

SP  2.4  Plan  for  Project  Resources 

SP  2.5  Plan  for  Needed  Knowledge  and  Skills 
SP  2.6  Plan  Stakeholder  Involvement 

SP  2.7  Establish  the  Project  Plan 

SP  2.8  Plan  for  Operations  and  Support 
SG  3  Obtain  Commitment  to  the  Plan 

SP  3.1  Review  Plans  That  Affect  the  Project 
SP  3.2  Reconcile  Work  and  Resource  Levels 

SP  3.3  Obtain  Plan  Commitment 


Specific  Practices  by  Goal 


SG  1  Establish  Estimates 

Estimates  of  project  planning  parameters  are  established  and  maintained. 

Project  planning  parameters  include  all  information  needed  by  the 
project  to  perform  the  necessary  planning,  organizing,  staffing, 
directing,  coordinating,  reporting,  and  budgeting. 

The  acquirer  develops  estimates  for  the  project  work,  including  high 
level  estimates  for  the  work  to  be  done  by  suppliers.  Initial  estimates 
may  be  revised  based  upon  the  suppliers’  estimates  in  responses  to  the 
solicitation  package,  [acq] 

Estimates  of  planning  parameters  should  have  a  sound  basis  to  instill 
confidence  that  any  plans  based  on  these  estimates  are  capable  of 
supporting  project  objectives. 

Factors  that  are  typically  considered  when  estimating  these  parameters 
include  the  following: 

•  Project  requirements,  including  the  product  requirements,  the 
requirements  imposed  by  the  organization,  the  requirements 
imposed  by  the  customer,  and  other  requirements  that  impact  the 
project 

•  Scope  of  the  project 

•  Identified  tasks  and  work  products 
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•  Technical  approach 

•  Selected  project  life-cycle  model  (e.g.,  waterfall,  incremental,  or 
spiral) 

•  Attributes  of  the  work  products  and  tasks  (e.g.,  size  or  complexity) 

•  Schedule 

•  Models  or  historical  data  for  converting  the  attributes  of  the  work 
products  and  tasks  into  labor  hours  and  cost 

•  Methodology  (e.g.,  models,  data,  algorithms)  used  to  determine 
needed  material,  skills,  labor  hours,  and  cost 

The  acquisition  strategy  is  a  key  factor  when  estimating  the  project,  [acqj 

Documentation  of  the  estimating  rationale  and  supporting  data  is 

needed  for  stakeholders’  review  and  commitment  to  the  plan  and  for 

maintenance  of  the  plan  as  the  project  progresses. 


SP  1.1  Estimate  the  Scope  of  the  Project 

Establish  a  top-level  work  breakdown  structure  (WBS)  to 
estimate  the  scope  of  the  project. 


The  acquirer  establishes  the  objectives  of  the  project.  Together  with  an 
initial  set  of  requirements  the  project  objectives  are  the  basis  for 
establishing  the  WBS  or  for  selecting  a  standard  WBS  from  the 
organization’s  process  assets.  The  WBS  includes  activities  performed 
by  the  acquirer  as  well  as  milestones  and  deliverables  for  the  suppliers. 

[ACQ] 


The  acquisition  strategy  drives  a  key  decision  in  this  practice, 
specifically  how  much  work,  and  what  work,  to  give  to  a  supplier.  The 
acquirer  develops  a  WBS  that  clearly  identifies  what  project  work  is 
performed  by  the  acquirer  and  what  project  work  is  performed  by  the 
supplier.  The  supplier  work  identified  in  the  WBS  becomes  the 
foundation  for  the  statement  of  work  defined  in  the  Solicitation  and 
Supplier  Agreement  Development  process  area.  The  WBS  identifies  the 
deliverables  from  the  supplier  and  the  work  products  developed  by  the 
acquirer,  [acqj 


The  WBS  evolves  with  the  project.  Initially  a  top-level  WBS  can  serve  to 
structure  the  initial  estimating.  The  development  of  a  WBS  divides  the 
overall  project  into  an  interconnected  set  of  manageable  components. 
Typically,  the  WBS  is  a  product  oriented  structure  that  provides  a 
scheme  for  identifying  and  organizing  the  logical  units  of  work  to  be 
managed,  which  are  called  “work  packages.”  The  WBS  provides  a 
reference  and  organizational  mechanism  for  assigning  effort,  schedule, 
and  responsibility  and  is  used  as  the  underlying  framework  to  plan, 
organize,  and  control  the  work  done  on  the  project. 
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Typical  Acquirer  Work  Products 

1.  Task  descriptions 

2.  Work  package  descriptions 

3.  WBS 

Subpractices 

1 .  Develop  a  WBS  based  on  the  product  architecture. 

The  WBS  should  permit  the  identification  of  the  following  items:  [acq] 

•  Identified  risks  and  their  mitigation  tasks 

•  Tasks  for  deliverables  and  supporting  activities 

•  Tasks  for  skill  and  knowledge  acquisition 

•  Tasks  for  development  of  needed  support  plans,  such  as  configuration 
management,  quality  assurance,  and  verification  plans 

•  Tasks  for  integration  and  management  of  nondevelopmental  items 

2.  Identify  the  work  packages  in  sufficient  detail  to  specify  estimates 
of  project  tasks,  responsibilities,  and  schedule. 

The  top-level  WBS  is  intended  to  help  in  gauging  the  project  work  effort  in  terms 
of  tasks  and  organizational  roles  and  responsibilities.  The  amount  of  detail  in  the 
WBS  at  this  more  detailed  level  helps  in  developing  realistic  schedules,  thereby 
minimizing  the  need  for  management  reserve,  [acqj 

3.  Identify  work  products  (or  components  of  work  products)  that  will 
be  externally  acquired. 

4.  Identify  work  products  that  will  be  reused. 

SP  1.2  Establish  Estimates  of  Work  Product  and  Task  Attributes 

Establish  and  maintain  estimates  of  the  attributes  of  the  work 
products  and  tasks. 


Size  is  the  primary  input  to  many  models  used  to  estimate  effort,  cost, 
and  schedule.  The  models  can  also  be  based  on  inputs  such  as 
connectivity,  complexity,  and  structure. 


Examples  of  types  of  work  products  for  which  size  estimates  are  made  include  the 
following: 

•  Deliverable  and  nondeliverable  work  products 

•  Documents  and  files 

•  Operational  and  support  hardware,  firmware,  and  software 
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Estimation  models  can  be  built  based  on  the  historical  data  as  part  of 
organizational  process  performance  and  estimates  for  any  project  to  be 
validated  using  these  models,  [acq] 

Refer  Organizational  Process  Performance  process  area  for  details  on 
how  to  build  process  performance  models,  [acq] 

Examples  of  size  measures  for  acquired  products  include  the  following:  [acqi 

•  Source  lines  of  code 

•  Number  of  function  points 

•  Number  of  interfaces  within  product  architecture. 

Examples  of  size  measures  include  the  following:  [acqi 

•  Number  of  functions 

•  Function  points 

•  Source  lines  of  code 

•  Number  of  classes  and  objects 

•  Number  of  requirements 

•  Number  and  complexity  of  interfaces 

•  Number  of  pages 

•  Number  of  inputs  and  outputs 

•  Number  of  technical  risk  items 

•  Volume  of  data 

•  Number  of  logic  gates  for  integrated  circuits 

•  Number  of  parts  (e.g.,  printed  circuit  boards,  components,  and  mechanical  parts) 

•  Physical  constraints  (e.g.,  weight  and  volume) 

Methods  for  estimation  include  using  historical  acquirer  and  supplier  data  and  standard 
estimating  models  to  compare  projects  of  similar  complexity.  Where  historical  size  data 
are  not  available,  develop  an  estimate  based  on  the  understanding  of  the  design  of 
similar  products,  [acqi 

The  estimates  should  be  consistent  with  project  requirements  to 
determine  the  project’s  effort,  cost,  and  schedule.  A  relative  level  of 
difficulty  or  complexity  should  be  assigned  for  each  size  attribute. 

Typical  Acquirer  Work  Products 

1.  Technical  approach 

2.  Size  and  complexity  of  tasks  and  work  products 
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3.  Estimating  models 

4.  Attribute  estimates 

Subpractices 

1 .  Determine  the  technical  approach  for  the  project. 

The  technical  approach  defines  a  top-level  strategy  for  development  of  the 
products.  It  includes  decisions  on  architectural  features,  such  as  distributed  or 
client/server;  state-of-the-art  or  established  technologies  to  be  applied,  such  as 
robotics,  composite  materials,  or  artificial  intelligence;  and  breadth  of  the 
functionality  expected  in  the  final  products,  such  as  safety,  security,  and 
ergonomics,  [acq] 

The  technical  approach  provides  a  basis  for  interoperability  and  supportability  of 
the  technical  solution  developed  by  the  supplier,  [acqi 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  defining  design  constraints,  [acq] 

2.  Use  appropriate  methods  to  determine  the  attributes  of  the  work 
products  and  tasks  that  will  be  used  to  estimate  the  resource 
requirements,  [acq] 

Methods  for  determining  size  and  complexity  should  be  based  on  validated 
models  or  historical  data,  [acq] 


Examples  of  attributes  include  the  following:  [acqi 

•  Maturity  of  the  technology  specified  in  the  technical  solution 

•  Amount  and  complexity  of  the  work  potentially  assigned  to  suppliers. 

•  Number  of  locations  where  the  product  is  to  be  installed 


The  methods  for  determining  attributes  evolve  as  our  understanding  of  the 
relationship  of  product  characteristics  to  attributes  increases,  [acq] 


Examples  of  current  methods  include  the  following:  [acqi 

•  Number  of  logic  gates  for  integrated  circuit  design 

•  Lines  of  code  or  function  points  for  software 

•  Number/complexity  of  requirements  for  systems  engineering 

•  Number  of  square  feet  for  standard-specified  residential  homes 


3.  Estimate  the  attributes  of  the  work  products  and  tasks. 


SP  1.3  Define  Project  Life  Cycle 

Define  the  project  life-cycle  phases  on  which  to  scope  the 
planning  effort. 
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The  determination  of  a  project’s  life-cycle  phases  provides  for  planned 
periods  of  evaluation  and  decision  making.  These  are  normally  defined 
to  support  logical  decision  points  at  which  significant  commitments  are 
made  concerning  resources  and  technical  approach.  Such  points 
provide  planned  events  at  which  project  course  corrections  and 
determinations  of  future  scope  and  cost  can  be  made. 

The  project  life  cycle  phases  need  to  be  defined  depending  on  the 
scope  of  requirements,  the  estimates  for  project  resources,  and  the 
nature  of  the  project,  [acq] 

The  acquirer  refines  the  acquisition  strategy  when  determining  the 
project  life  cycle  phases.  Include  in  the  planning  the  entire  known  life 
cycle  from  user  needs  through  initial  and  subsequent  upgrades.  The 
acquirer  considers  all  supplier  agreements  within  the  context  of  the 
acquisition  so  that  an  integrated  approach  results,  rather  than  dealing 
with  activities  individually.  A  complex  project  can  involve  managing 
multiple  supplier  agreements  simultaneously  or  in  sequence.  In  such 
cases,  any  acquisition  life  cycle  can  end  during  any  phase  of  the  project 
life  cycle.  Depending  on  the  acquisition  strategy,  there  may  be 
intermediate  phases  for  the  creation  of  prototypes,  increments  of 
capability,  or  spiral  model  cycles,  [acq] 

An  acquirer’s  understanding  of  suppliers’  life-cycle  models  and 
processes,  especially  those  that  interact  directly  with  the  acquirer’s 
processes,  enables  seamless  interactions  between  supplier  and 
acquirer,  resulting  in  a  successful  acquirer-supplier  relationship,  [acq] 

Understanding  the  project  life  cycle  is  crucial  in  determining  the  scope 
of  the  planning  effort  and  the  timing  of  the  initial  planning,  as  well  as  the 
timing  and  criteria  (critical  milestones)  for  replanning. 

Typical  Acquirer  Work  Products 

1 .  Project  life-cycle  phases 

Refer  to  the  Organization  Process  Definition  process  area  for  more 
information  about  choosing  the  life-cycle  approach,  [acq] 


SP  1.4  Determine  Estimates  of  Effort  and  Cost 

Estimate  the  project  effort  and  cost  for  the  work  products  and 
tasks  based  on  estimation  rationale. 
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Estimates  of  effort  and  cost  are  generally  based  on  the  results  of 
analysis  using  models  or  historical  data  applied  to  size,  activities,  and 
other  planning  parameters.  Confidence  in  these  estimates  is  based  on 
the  rationale  for  the  selected  model  and  the  nature  of  the  data.  There 
may  be  occasions  when  the  available  historical  data  does  not  apply, 
such  as  where  efforts  are  unprecedented  or  where  the  type  of  task  does 
not  fit  available  models.  An  effort  is  unprecedented  (to  some  degree)  if 
a  similar  product  or  component  has  never  been  built. 

Unprecedented  efforts  are  more  risky,  require  more  research  to  develop 
reasonable  bases  of  estimate,  and  require  more  management  reserve. 
The  uniqueness  of  the  project  must  be  documented  when  using  these 
models  to  ensure  a  common  understanding  of  any  assumptions  made 
in  the  initial  planning  stages. 

Estimates  address  all  processes  and  activities  performed  by  the  project 
for  the  project  life  cycle,  including  an  estimate  of  effort  and  cost  for  the 
supplier’s  work.  The  project  estimate  includes  detailed  estimates  for 
activities  performed  by  the  acquirer  and  its  stakeholders.  As  the  project 
evolves,  these  estimates  may  be  revised  based  upon  changed 
conditions  (e.g.,  new  circumstances  during  execution  of  the  supplier 
agreement),  [acqj 

In  addition  to  creating  an  estimation  of  the  project  work  products,  the 
acquirer  is  encouraged  to  have  its  estimate  independently  reviewed  by 
individuals  external  to  the  project  to  ensure  that  the  project  estimation 
can  be  validated.  Be  sure  to  include  the  effort  and  cost  supporting 
execution  of  the  acquirer’s  processes  as  well  as  developing  the  product. 

[ACQ] 

Typical  Acquirer  Work  Products 

1.  Estimation  rationale 

2.  Project  effort  estimates 

3.  Project  cost  estimates 

Subpractices 

1 .  Collect  the  models  or  historical  data  that  will  be  used  to  transform 
the  attributes  of  the  work  products  and  tasks  into  estimates  of  the 
labor  hours  and  cost. 

Effort  estimation  at  the  work  product  and  task  level  needs  to  be  done  for  the 
acquirer  work.  Estimation  at  a  higher  level  should  be  sufficient  for  supplier 
deliverables  and  processes,  [acqj 
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Many  parametric  models  have  been  developed  to  aid  in  estimating  cost  and 
schedule.  The  use  of  these  models  as  the  sole  source  of  estimation  is  not 
recommended  because  these  models  are  based  on  historical  project  data  that 
may  or  may  not  be  pertinent  to  your  project.  Multiple  models  and/or  methods  can 
be  used  to  ensure  a  high  level  of  confidence  in  the  estimate,  [acqj 

Historical  data  include  the  cost,  effort,  and  schedule  data  from  previously 
executed  projects,  plus  appropriate  scaling  data  to  account  for  differing  sizes  and 
complexity,  [acqi 

2.  Include  supporting  infrastructure  needs  when  estimating  effort  and 
cost. 

Examples  of  supporting  infrastructure  typically  provided  by  the  supplier  include 
:  the  following:  [acq] 

i  •  Critical  computing  resources  in  the  host  and  testing  environment  (e.g.,  memory, 
disk  and  network  capability) 

:  •  Test  equipment 

3.  Estimate  effort  and  cost  using  models  and/or  historical  data. 

Effort  and  cost  inputs  used  for  estimating  typically  include  the  following:  [acqi 

•  Judgmental  estimates  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi 
Method) 

•  Estimates  for  development  of  requirements 

•  Risks,  including  the  extent  to  which  the  effort  is  unprecedented 

•  Critical  competencies  and  roles  needed  to  perform  the  work 

•  WBS 

•  Cost  of  acquired  work  products 

•  Selected  project  life-cycle  model  and  processes 

•  Life-cycle  cost  estimates 

•  Skill  levels  of  managers  and  staff  needed  to  perform  the  work 

•  Knowledge,  skill,  and  training  needs 

•  Facilities  needed  (e.g.,  office  and  meeting  space  and  workstations) 

•  Travel 

•  Level  of  security  required  for  tasks,  work  products,  hardware,  software,  personnel, 
and  work  environment 

•  Service  level  agreements  for  call  centers  and  warranty  work 

•  Direct  labor  and  overhead 
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The  amount  of  supplier  work  for  a  project  largely  determines  the  amount  of 
acquirer  work  to  manage  the  project  and  the  supplier.  Estimate  supplier  work  at  a 
high  level;  acquirer  work  at  a  more  detailed  level.  Effort  for  the  acquirer  include  (1) 
effort  associated  with  defining  the  scope  of  the  project,  (2)  effort  associated  with 
the  development  and  deployment  of  the  technical  solution,  (3)  operating  and 
maintenance  effort  associated  with  the  sustainment  of  the  solution,  and  (4) 
disposal  effort,  [acqi 


SG  2  Develop  a  Project  Plan 

A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 
project. 

A  project  plan  is  a  formal,  approved  document  used  to  manage  and 
control  the  execution  of  the  project.  It  is  based  on  the  project 
requirements  and  the  established  estimates. 

The  project  plan  should  consider  all  phases  of  the  project  life  cycle. 
Project  planning  should  ensure  that  all  plans  affecting  the  project  are 
consistent  with  the  overall  project  plan. 


SP  2.1  Establish  the  Budget  and  Schedule 

Establish  and  maintain  the  project’s  budget  and  schedule. 


The  project’s  budget  and  schedule  are  based  on  the  developed 
estimates  and  ensure  that  budget  allocation,  task  complexity,  and  task 
dependencies  are  appropriately  addressed. 

The  project’s  budget  and  schedule,  including  the  life-cycle-related 
activities  of  the  acquirer,  the  supplier’s  efforts,  and  those  of  the 
supporting  organizations  and  other  stakeholders,  including  any 
contractors  to  support  the  acquirer,  are  created  and  maintained  for  the 
duration  of  the  project,  [acq] 

Event-driven,  resource-limited  schedules  have  proven  to  be  effective  in 
dealing  with  project  risk.  Identifying  accomplishments  to  be 
demonstrated  before  initiation  of  the  event  provides  some  flexibility  in 
the  timing  of  the  event,  a  common  understanding  of  what  is  expected,  a 
better  vision  of  the  state  of  the  project,  and  a  more  accurate  status  of 
the  project’s  tasks. 

Typical  Acquirer  Work  Products 

1.  Project  schedules 

2.  Schedule  dependencies 

3.  Project  budget 

Subpractices 

1 .  Identify  major  milestones. 
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Milestones  are  often  imposed  to  ensure  completion  of  certain  deliverables  by  the 
milestone.  Milestones  can  be  event  based  or  calendar  based.  If  calendar  based, 
once  milestone  dates  have  been  agreed  on,  it  is  often  very  difficult  to  change 
them,  [acq] 

2.  Identify  schedule  assumptions. 

When  schedules  are  initially  developed,  it  is  common  to  make  assumptions  about 
the  duration  of  certain  activities.  These  assumptions  are  frequently  made  on  items 
for  which  little  if  any  estimation  data  is  available.  Identifying  these  assumptions 
provides  insight  into  the  level  of  confidence  (uncertainties)  in  the  overall  schedule. 

[ACQ] 

3.  Identify  constraints. 

Factors  that  limit  the  flexibility  of  management  options  need  to  be  identified  as 
early  as  possible.  The  examination  of  the  attributes  of  the  work  products  and 
tasks  often  will  bring  these  issues  to  the  surface.  Such  attributes  can  include  task 
duration,  resources,  inputs,  and  outputs,  [acq] 

Since  the  characteristics  of  pre-qualified  or  other  potential  suppliers  including 
technical  and  financial  capability,  management  and  delivery  processes, 
production  capacity,  business  type  and  size  are  a  key  element  of  project  success, 
the  acquirer  considers  these  characteristics  in  identifying  constraints  for  the 
project,  [acq] 

4.  Identify  task  dependencies. 

Typically,  the  tasks  for  a  project  can  be  accomplished  in  some  ordered  sequence 
that  will  minimize  the  duration  of  the  project.  This  involves  the  identification  of 
predecessor  and  successor  tasks  to  determine  the  optimal  ordering,  [acqj 


Examples  of  tools  that  can  help  determine  an  optimal  ordering  of  task  activities 
include  the  following:  [acqj 

•  Critical  Path  Method  (CPM) 

•  Program  Evaluation  and  Review  Technique  (PERT) 

•  Resource-limited  scheduling 

•  Critical  chain  method 


5.  Define  the  budget  and  schedule. 

Establishing  and  maintaining  the  project’s  budget  and  schedule  typically  includes 
the  following:  [acqj 

•  Defining  the  committed  or  expected  availability  of  resources  and  facilities 

•  Determining  time  phasing  of  activities 

•  Determining  a  breakout  of  subordinate  schedules 


266 


Project  Planning 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


•  Defining  the  dependencies  between  the  activities  (predecessor  or  successor 
relationships) 

•  Defining  the  schedule  activities  and  milestones  to  support  accuracy  in  progress 
measurement 

•  Identifying  milestones  for  delivery  of  products  to  the  customer 

•  Defining  activities  of  appropriate  duration 

•  Defining  milestones  of  appropriate  time  separation 

•  Defining  a  management  reserve  based  on  the  confidence  level  in  meeting  the 
schedule  and  budget 

•  Using  appropriate  historical  data  to  verify  the  schedule 

•  Defining  incremental  funding  requirements 

•  Documenting  project  assumptions  and  rationale 

•  Determining  the  approach  for  incorporation  of  supplier  schedules  at  an 
appropriate  level  of  detail 

6.  Establish  corrective  action  criteria. 

Criteria  are  established  for  determining  what  constitutes  a  significant  deviation 
from  the  project  plan.  A  basis  for  gauging  issues  and  problems  is  necessary  to 
determine  when  a  corrective  action  should  be  taken.  The  corrective  actions  may 
require  replanning,  which  may  include  revising  the  original  plan,  establishing  new 
agreements,  or  including  mitigation  activities  within  the  current  plan,  [acqi 


SP  2.2  Identify  Project  Risks 

Identify  and  analyze  project  risks. 


Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities. 

Refer  to  the  Monitor  Project  Risks  specific  practice  in  the  Project 
Monitoring  and  Control  process  area  for  more  information  about  risk 
monitoring  activities. 

Risks  are  identified  or  discovered  and  analyzed  to  support  project 
planning.  This  specific  practice  should  be  extended  to  all  the  plans  that 
affect  the  project  to  ensure  that  the  appropriate  interfacing  is  taking 
place  between  all  relevant  stakeholders  on  identified  risks.  Project 
planning  risk  identification  and  analysis  typically  include  the  following: 

•  Identifying  risks 

•  Analyzing  the  risks  to  determine  the  impact,  probability  of 
occurrence,  and  time  frame  in  which  problems  are  likely  to  occur 

•  Prioritizing  risks 
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Risks  are  identified  from  multiple  perspectives  (e.g.,  acquisition, 
technical,  management,  operational,  supplier  agreement,  industry, 
support,  and  user)  to  ensure  all  project  risks  are  considered 
comprehensively  in  planning  activities.  Applicable  regulatory  and 
statutory  requirements  with  respect  to  safety  and  security  must  be 
considered  while  identifying  risks,  [acq] 

Together  with  the  acquisition  strategy,  the  risks  identified  in  project 
planning  form  the  basis  for  some  of  the  criteria  used  in  the  evaluation 
practices  in  Solicitation  and  Supplier  Agreement  Development.  As  the 
project  evolves,  risks  may  be  revised  based  upon  changed  conditions 
(e.g.,  new  circumstances  during  execution  of  the  supplier  agreement). 

[ACQ] 

Typical  Acquirer  Work  Products 

1.  Identified  risks 

2.  Risk  impacts  and  probability  of  occurrence 

3.  Risk  priorities 

Subpractices 
1 .  Identify  risks. 

The  identification  of  risks  involves  the  identification  of  potential  issues,  hazards, 
threats,  vulnerabilities,  and  so  on  that  could  negatively  affect  work  efforts  and 
plans.  Risks  must  be  identified  and  described  in  an  understandable  way  before 
they  can  be  analyzed.  When  identifying  risks,  it  is  good  to  use  a  standard  method 
for  defining  risks.  Risk  identification  and  analysis  tools  can  be  used  to  help  identify 
possible  problems,  [acqi 


Examples  of  risk  identification  and  analysis  tools  include  the  following:  [acqi 

•  Risk  taxonomies 

•  Risk  assessments 

•  Checklists 

•  Structured  interviews 

•  Brainstorming 

•  Performance  models 

•  Cost  models 

•  Network  analysis 

•  Quality  factor  analysis 


2.  Identify  risks  associated  with  the  acquisition,  [acq] 
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There  are  numerous  risks  that  are  associated  with  acquiring  products  through 
suppliers  (e.g.,  the  stability  of  the  supplier,  the  ability  to  maintain  sufficient  insight 
into  the  progress  of  their  work,  the  supplier’s  capability  to  meet  the  product 
requirements,  and  the  skills  and  availability  of  supplier  resources  to  meet 
commitments),  [acq] 

3.  Document  the  risks. 

4.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
completeness  and  correctness  of  the  documented  risks. 

5.  Revise  the  risks  as  appropriate. 


Examples  of  when  identified  risks  may  need  to  be  revised  include  the  following: 

[ACQ] 

•  When  new  risk  is  identified 

•  When  risks  become  problems 

•  When  risks  are  retired 

•  When  project  circumstances  change  significantly 


SP  2.3  Plan  for  Data  Management 

Plan  for  the  management  of  project  data. 


Data  are  the  various  forms  of  documentation  required  to  support  a 
program  in  all  of  its  areas  (e.g.,  administration,  engineering, 
configuration  management,  financial,  logistics,  quality,  safety, 
manufacturing,  and  procurement).  The  data  can  take  any  form  (e.g., 
reports,  manuals,  notebooks,  charts,  drawings,  specifications,  files,  or 
correspondence).  The  data  may  exist  in  any  medium  (e.g.,  printed  or 
drawn  on  various  materials,  photographs,  electronic,  or  multimedia). 
Data  may  be  deliverable  (e.g.,  items  identified  by  a  program’s  contract 
data  requirements)  or  data  may  be  nondeliverable  (e.g.,  informal  data, 
trade  studies  and  analyses,  internal  meeting  minutes,  internal  design 
review  documentation,  lessons  learned,  and  action  items).  Distribution 
can  take  many  forms,  including  electronic  transmission. 

The  data  requirements  for  the  project  should  be  established  for  both  the 
data  items  to  be  created  and  their  content  and  form,  based  on  a 
common  or  standard  set  of  data  requirements.  Uniform  content  and 
format  requirements  for  data  items  facilitate  understanding  of  data 
content  and  help  with  consistent  management  of  the  data  resources. 

The  reason  for  collecting  each  document  should  be  clear.  This  task 
includes  the  analysis  and  verification  of  project  deliverables  and 
nondeliverables,  contract  and  noncontract  data  requirements,  and 
customer-supplied  data.  Often,  data  is  collected  with  no  clear 
understanding  of  how  it  will  be  used.  Data  is  costly  and  should  be 
collected  only  when  needed. 
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This  includes  both  acquirer  and  supplier  created  data.  The  acquirer 
identifies  the  minimal  data  required  to  cost-effectively  operate,  maintain, 
and  improve  the  acquired  product  and  to  foster  source  of  support 
competition  throughout  the  product’s  life  cycle  in  the  acquirer’s  intended 
environment.  Data  should  be  available  in  a  format  that  is  compatible 
with  the  intended  user's  environment  and  a  quality  assurance  program 
should  be  implemented  to  guarantee  the  accuracy  and  completeness  of 
the  data,  [acq] 

Consider  how  data  will  be  shared  between  acquirer  and  supplier  as  well 
as  across  relevant  stakeholders.  In  many  cases,  leaving  acquirer  data 
in  the  physical  possession  of  the  supplier  and  having  access  to  the 
supplier’s  data  is  the  preferred  solution.  In  addition  to  data  access,  the 
requirement  for  acquirer  use,  reproduction,  manipulation,  altering  or 
transfer  of  possession  of  data  should  be  part  of  the  data  management 
plan.  The  supplier  agreement  specifies  appropriate  acquirer  rights  to 
the  data  acquired,  in  addition  to  requirements  for  delivery  or  access. 
Data,  whenever  it  is  delivered  to  the  acquirer,  is  formatted  in 
accordance  with  accepted  data  standards  to  ensure  usability  by  the 
acquirer.  Planning  for  managing  data,  including  during  transition  to 
operations  and  support,  is  addressed  as  part  of  project  planning  to 
avoid  unexpected  costs  to  procure,  reformat,  and  deliver  data.  Include 
plans  for  managing  data  within  the  project  teams  and  the  infrastructure 
required  to  manage  data  between  the  supplier,  operational  users,  and 
other  relevant  stakeholders.  Decide  which  project  data  and  plans 
require  version  control,  or  more  stringent  levels  of  configuration  control, 
and  establish  mechanisms  to  ensure  project  data  is  controlled. 

Consider  the  implications  of  controlling  access  to  classified  and 
sensitive  data  (e.g.,  proprietary,  export  controlled,  source  selection 
sensitive)  and  other  access  controlled  data,  [acq] 

Typical  Acquirer  Work  Products 

1.  Data  management  plan 

2.  Master  list  of  managed  data 

3.  Data  content  and  format  description 

4.  Data  requirements  lists  for  acquirers  and  for  suppliers 

5.  Privacy  requirements 

6.  Security  requirements 

7.  Security  procedures 

8.  Mechanism  for  data  retrieval,  reproduction,  and  distribution 

9.  Schedule  for  collection  of  project  data 

10.  Listing  of  project  data  to  be  collected 
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Subpractices 

1 .  Establish  requirements  and  procedures  to  ensure  privacy  and 
security  of  the  data. 

Not  everyone  will  have  the  need  or  clearance  necessary  to  access  the  project 
data.  Procedures  must  be  established  to  identify  who  has  access  to  what  data  as 
well  as  when  they  have  access  to  the  data,  [acqj 

Security  and  access  control  are  critical  when  the  acquirer  provides  data  access  to 
the  supplier.  This  includes  access  lists  of  authorized  supplier  personnel  and  non¬ 
disclosure  agreements  between  acquirer  and  supplier.  For  example,  when  the 
supplier  performs  work  for  the  acquirer  off-site  (e.g.,  off-shore  development 
center)  then  the  acquirer  needs  to  consider  additional  security  measures  like 
firewall  between  the  acquirer’s  and  the  supplier’s  network  and  restricted  access  to 
the  acquirer’s  work  place,  [acqj 

2.  Establish  a  mechanism  to  archive  data  and  to  access  archived 
data. 

Accessed  information  should  be  in  an  understandable  form  (e.g.,  electronic  or 
computer  output  from  a  database)  or  represented  as  originally  generated,  [acqi 

The  data  management  plan  is  ideally  supported  by  an  integrated  data  system  that 
meets  the  needs  of  both  initial  acquisition  and  the  support  community.  Integrating 
acquisition  and  sustainment  data  systems  into  a  total  life  cycle  integrated  data 
environment  provides  the  capability  needed  to  plan  effectively  for  sustainment  and 
to  facilitate  technology  insertion  for  affordability  improvements  during  re¬ 
procurement  and  post-production  support,  while  also  insuring  that  acquisition 
planners  have  accurate  information  about  total  life  cycle  costs,  [acqj 

3.  Determine  the  project  data  to  be  identified,  collected,  and 
distributed. 


SP  2.4  Plan  for  Project  Resources 

Plan  for  necessary  resources  to  perform  the  project. 


Defining  project  resources  (labor,  machinery/equipment,  materials,  and 
methods)  and  quantities  needed  to  perform  project  activities  builds  on 
the  initial  estimates  and  provides  additional  information  that  can  be 
applied  to  expand  the  WBS  used  to  manage  the  project. 
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The  top-level  WBS  developed  earlier  as  an  estimation  mechanism  is 
typically  expanded  by  decomposing  these  top  levels  into  work  packages 
that  represent  singular  work  units  that  can  be  separately  assigned, 
performed,  and  tracked.  This  subdivision  is  done  to  distribute 
management  responsibility  and  provide  better  management  control. 
Each  work  package  or  work  product  in  the  WBS  should  be  assigned  a 
unique  identifier  (e.g.,  number)  to  permit  tracking.  A  WBS  can  be  based 
on  requirements,  activities,  work  products,  or  a  combination  of  these 
items.  A  dictionary  that  describes  the  work  for  each  work  package  in  the 
WBS  should  accompany  the  work  breakdown  structure. 

The  resource  plan  needs  to  include  planning  for  staff  with  appropriate 
training  and  experience  to  evaluate  supplier  proposals  and  to 
participate  in  negotiations  with  suppliers.  It  also  identifies  the  project 
resources  expected  from  the  supplier.  This  includes  any  critical  facilities 
or  equipment  needed  to  support  the  work  packages  and  determines 
which  will  be  provided  by  the  supplier.  The  resource  plan  may  be 
revised  based  upon  the  supplier  agreement  or  changed  conditions 
during  execution  of  the  project,  [acq] 

Typical  Acquirer  Work  Products 

1 .  WBS  work  packages 

2.  WBS  task  dictionary 

3.  Staffing  requirements  based  on  project  size  and  scope 

4.  Critical  facilities/equipment  list 

5.  Process/workflow  definitions  and  diagrams 

6.  Program  administration  requirements  list 

Subpractices 

1.  Determine  process  requirements. 

The  processes  used  to  manage  a  project  must  be  identified,  defined,  and 
coordinated  with  all  the  relevant  stakeholders  to  ensure  efficient  operations  during 
project  execution,  [acqj 

The  acquirer  must  also  determine  how  the  acquirer’s  processes  interact  with  the 
supplier’s  processes  to  enable  a  seamless  execution  of  the  project  and  a 
successful  acquirer-supplier  relationship,  [acqi 

2.  Determine  staffing  requirements. 

The  staffing  of  a  project  depends  on  the  decomposition  of  the  project 
requirements  into  tasks,  roles,  and  responsibilities  for  accomplishing  the  project 
requirements  as  laid  out  within  the  work  packages  of  the  WBS.  [acq] 
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Staffing  requirements  must  consider  the  knowledge  and  skills  required  for  each  of 
the  identified  positions,  as  defined  in  the  Plan  for  Needed  Knowledge  and  Skills 
specific  practice,  [acqj 

The  acquirer  determines  its  staffing  requirements,  including  staffing  for  solicitation 
and  supplier  agreement  management,  and  the  staffing  expected  by  the  supplier  to 
complete  their  portion  of  the  work  as  defined  in  the  WBS.  [acq] 

3.  Determine  facilities,  equipment,  and  component  requirements. 

Most  projects  are  unique  in  some  sense  and  require  some  set  of  unique  assets  to 
accomplish  the  objectives  of  the  project.  The  determination  and  acquisition  of 
these  assets  in  a  timely  manner  are  crucial  to  project  success,  [acqi 

Lead-time  items  need  to  be  identified  early  to  determine  how  they  will  be 
addressed.  Even  when  the  required  assets  are  not  unique,  compiling  a  list  of  all  of 
the  facilities,  equipment,  and  parts  (e.g.,  number  of  computers  for  the  personnel 
working  on  the  project,  software  applications,  and  office  space)  provides  insight 
into  aspects  of  the  scope  of  an  effort  that  are  often  overlooked,  [acq] 

The  acquirer  considers  what  facilities  and  equipment  must  be  provided  by  the 
supplier,  as  well  as  what  the  acquirer  may  need  to  provide  for  acceptance  of  the 
supplier  deliverables,  transition  and  support  of  the  acquired  product.  The  acquirer 
must  include  any  facility  or  equipment  requirements  for  the  supplier  in  the  supplier 
agreement,  [acq] 


The  acquirer  must  also  identify  and  ensure  that  any  facilities  or  equipment  to  be 
provided  to  the  supplier  for  their  project  work  are  accounted  for  in  the  project  plan. 

[ACQ] 


SP  2.5  Plan  for  Needed  Knowledge  and  Skills 

Plan  for  knowledge  and  skills  needed  to  perform  the  project. 


Refer  to  the  Organizational  Training  process  area  for  more  information 
about  knowledge  and  skills  information  to  be  incorporated  into  the 
project  plan. 

Knowledge  delivery  to  projects  involves  both  training  of  project 
personnel  and  acquisition  of  knowledge  from  outside  sources. 

Staffing  requirements  are  dependent  on  the  knowledge  and  skills 
available  to  support  the  execution  of  the  project. 
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Plan  for  knowledge  and  skills  required  by  the  project  team  to  perform 
their  tasks.  Knowledge  and  skill  requirements  can  be  derived  from 
project  risk.  For  example,  if  the  acquirer  is  purchasing  a  software¬ 
intensive  product,  ensure  the  personnel  from  the  acquirer  that  is 
assigned  to  the  project  has  expertise  in  systems  and  software 
engineering,  or  provide  training  for  the  acquirer’s  project  team  in  these 
areas.  Include  orientation  and  training  for  acquirer  in  Solicitation  and 
Supplier  Agreement  Development  and  the  domain  knowledge  required 
to  execute  the  project.  The  acquirer  also  plans  for  the  knowledge  and 
skills  needed  from  the  supplier.  For  example,  the  acquirer  can  provide 
specific  role  descriptions  and  skill  profiles  to  the  supplier  as  part  of  the 
solicitation  package,  [acqj 

Training  includes  ensuring  appropriate  training  is  planned  for  personnel 
involved  in  receiving,  storing,  using,  and  supporting  the  transitioned 
product  and  that  costs  and  funding  sources  to  pay  for  training  and  lead 
times  to  obtain  the  funding  are  identified,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Inventory  of  skill  needs 

2.  Staffing  and  new  hire  plans 

3.  Databases  (e.g.,  skills  and  training) 

4.  Training  Plans  [acq] 

Subpractices 

1 .  Identify  the  knowledge  and  skills  needed  to  perform  the  project. 

2.  Assess  the  knowledge  and  skills  available. 

3.  Select  mechanisms  for  providing  needed  knowledge  and  skills. 


Example  mechanisms  include  the  following:  [acqi 

•  In-house  training  (both  organizational  and  project) 

•  External  training 

•  Staffing  and  new  hires 

•  External  skill  acquisition 


The  choice  of  in-house  training  or  outsourced  training  for  the  needed  knowledge 
and  skills  is  determined  by  the  availability  of  training  expertise,  the  project’s 
schedule,  and  the  business  objectives,  [acq] 

4.  Incorporate  selected  mechanisms  into  the  project  plan. 


SP  2.6  Plan  Stakeholder  Involvement 

Plan  the  involvement  of  identified  stakeholders. 
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Stakeholders  are  identified  from  all  phases  of  the  project  life  cycle  by 
identifying  the  type  of  people  and  functions  needing  representation  in 
the  project  and  describing  their  relevance  and  the  degree  of  interaction 
for  specific  project  activities.  A  two-dimensional  matrix  with 
stakeholders  along  one  axis  and  project  activities  along  the  other  axis  is 
a  convenient  format  for  accomplishing  this  identification.  Relevance  of 
the  stakeholder  to  the  activity  in  a  particular  project  phase  and  the 
amount  of  interaction  expected  would  be  shown  at  the  intersection  of 
the  project  phase  activity  axis  and  the  stakeholder  axis. 

Stakeholders  can  include  operational  users  and  project  participants  as 
well  as  potential  suppliers.  When  acquiring  products  that  need  to 
interoperate  with  other  products,  plan  for  involvement  of  stakeholders 
from  other  projects  or  communities  to  ensure  the  delivered  product  can 
perform  as  required  in  its  intended  environment  [acq] 

For  the  inputs  of  stakeholders  to  be  useful,  careful  selection  of  relevant 
stakeholders  is  necessary.  For  each  major  activity,  identify  the 
stakeholders  who  are  affected  by  the  activity  and  those  who  have 
expertise  that  is  needed  to  conduct  the  activity.  This  list  of  relevant 
stakeholders  will  probably  change  as  the  project  moves  through  the 
phases  of  the  project  life  cycle.  It  is  important,  however,  to  ensure  that 
relevant  stakeholders  in  the  latter  phases  of  the  life  cycle  have  early 
input  to  requirements  and  design  decisions  that  affect  them. 


Examples  of  the  type  of  material  that  should  be  included  in  a  plan  for  stakeholder 

interaction  include  the  following: 

•  List  of  all  relevant  stakeholders 

•  Rationale  for  stakeholder  involvement 

•  Roles  and  responsibilities  of  the  relevant  stakeholders  with  respect  to  the  project, 
by  project  life-cycle  phase 

•  Relationships  between  stakeholders 

•  Relative  importance  of  the  stakeholder  to  success  of  the  project,  by  project  life- 
cycle  phase 

•  Resources  (e.g.,  training,  materials,  time,  funding)  needed  to  ensure  stakeholder 
interaction 

•  Schedule  for  phasing  of  stakeholder  interaction 


Conduct  of  this  specific  practice  relies  on  shared  or  exchanged 
information  with  the  previous  Plan  for  Needed  Knowledge  and  Skills 
specific  practice. 

Typical  Acquirer  Work  Products 
1 .  Stakeholder  involvement  plan 
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SP  2.7  Establish  the  Project  Plan 

Establish  and  maintain  the  overall  project  plan  content. 


A  documented  plan  that  addresses  all  relevant  planning  items  is 
necessary  to  achieve  the  mutual  understanding,  commitment,  and 
performance  of  individuals,  groups,  and  organizations  that  must 
execute  or  support  the  plans.  The  plan  generated  for  the  project  defines 
all  aspects  of  the  effort,  tying  together  in  a  logical  manner:  project  life- 
cycle  considerations;  technical  and  management  tasks;  budgets  and 
schedules;  milestones;  data  management,  risk  identification,  resource 
and  skill  requirements;  and  stakeholder  identification  and  interaction. 
Infrastructure  descriptions  include  responsibility  and  authority 
relationships  for  project  staff,  management,  and  support  organizations. 

The  project  plan  may  include  multiple  plans  such  as  staffing  plans, 
stakeholder  involvement  plans,  risk  mitigation  plans,  transition  plans, 
quality  assurance  plans,  and  configuration  management  plans. 
Regardless  of  form,  the  plan  or  plans  should  address  the  acquisition 
strategy  as  well  as  the  cradle-to-grave  considerations  for  the  project 
and  product  to  be  acquired,  [acqj 


Examples  of  plans  that  have  been  used  in  the  U.S.  Department  of  Defense  community 

include  the  following: 

•  Integrated  Master  Plan— an  event-driven  plan  that  documents  significant 
accomplishments  with  pass/fail  criteria  for  both  business  and  technical  elements  of 
the  project  and  that  ties  each  accomplishment  to  a  key  program  event. 

•  Integrated  Master  Schedule— an  integrated  and  networked  multi-layered  schedule 
of  program  tasks  required  to  complete  the  work  effort  documented  in  a  related 
Integrated  Master  Plan. 

•  Systems  Engineering  Management  Plan— a  plan  that  details  the  integrated 
technical  effort  across  the  project. 

•  Systems  Engineering  Master  Schedule— an  event-based  schedule  that  contains  a 
compilation  of  key  technical  accomplishments,  each  with  measurable  criteria, 
requiring  successful  completion  to  pass  identified  events. 

•  Systems  Engineering  Detailed  Schedule— a  detailed,  time-dependent,  task 

oriented  schedule  that  associates  specific  dates  and  milestones  with  the 
Systems  Engineering  Master  Schedule. 
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A  documented  plan  that  addresses  all  relevant  planning  items  is 
necessary  to  achieve  the  mutual  understanding,  commitment,  and 
performance  of  individuals,  groups,  and  organizations  that  must 
execute  or  support  the  plans.  The  plan  generated  for  the  project  defines 
all  aspects  of  the  effort,  tying  together  in  a  logical  manner:  project  life- 
cycle  considerations;  technical  and  management  tasks;  budgets  and 
schedules;  milestones;  data  management,  risk  identification,  resource 
and  skill  requirements;  and  stakeholder  identification  and  interaction. 
Infrastructure  descriptions  include  responsibility  and  authority 
relationships  for  project  staff,  management,  and  support  organizations. 

Typical  Acquirer  Work  Products 
1 .  Overall  project  plan 

SP  2.8  Plan  for  Operations  and  Support  [acqi 

Plan  for  transition  and  life  cycle  operations  and  support  for  the 
product,  [acq] 


Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  incorporating  requirements  and  plans 
for  transitioning  the  product  to  operations  and  support  in  the  solicitation 
package,  [acq] 

Planning  for  transition  must  be  considered  as  part  of  the  initial  planning 
for  the  project,  [acq] 

The  transition  and  support  plans  include  the  approach  for  introducing 
and  maintaining  the  readiness,  sustainment,  and  operational  capability 
of  the  product(s)  delivered  by  the  supplier.  Plans  for  transitioning  to 
operations  and  support  include  assignment  of  responsibility  for 
transition  to  operations  and  for  support  of  the  product,  as  well  as  all 
activities  needed  to  manage  the  transition  and  support  of  the  product  in 
the  intended  environment,  for  example,  definition  of  transition  readiness 
criteria  agreed  to  by  relevant  stakeholders.  These  plans  include 
reasonable  accommodations  for  potential  risks  and  for  the  evolution  of 
acquired  products  and  their  eventual  removal  from  operational  use.  [acq] 

The  transition  to  operations  and  support  plans  typically  include  the 
following:  [acq] 

•  Standard  processes  and  procedures  for  the  transition  to  operations 
and  support 

•  Verification  methods  and  acceptance  criteria  for  transitioning  the 
product  to  operations  and  support 

•  Readiness  criteria  for  the  product 

•  Readiness  criteria  for  the  operations  organization 

•  Readiness  criteria  for  the  product  support  organization 
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SG  3 


•  Expectations  for  supplier’s  execution  of  the  transition 

•  Warranty  expectations  for  the  acquired  product 

•  Resolution  of  any  problems  encountered 

Typically,  the  acquirer  develops  initial  transition  and  support  plans,  and 
then  reviews  and  approves  more  detailed  transition  and  support  plans 
developed  and  executed  by  the  supplier  as  defined  in  the  supplier 
agreement,  [acqj 

Typical  Acquirer  Work  Products 

1 .  T ransition  to  Operations  and  Support  Plans  [acq] 


Obtain  Commitment  to  the  Plan 

Commitments  to  the  project  plan  are  established  and  maintained. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  supplier  agreements  and  finalizing 
supplier  plans,  [acq] 

To  be  effective,  plans  require  commitment  by  those  responsible  for 
implementing  and  supporting  the  plan. 


SP  3.1  Review  Plans  That  Affect  the  Project 

Review  all  plans  that  affect  the  project  to  understand  project 
commitments. 


Plans  developed  within  other  process  areas  will  typically  contain 
information  similar  to  that  called  for  in  the  overall  project  plan.  These 
plans  may  provide  additional  detailed  guidance  and  should  be 
compatible  with  and  support  the  overall  project  plan  to  indicate  who  has 
the  authority,  responsibility,  accountability,  and  control.  All  plans  that 
affect  the  project  should  be  reviewed  to  ensure  a  common 
understanding  of  the  scope,  objectives,  roles,  and  relationships  that  are 
required  for  the  project  to  be  successful.  Many  of  these  plans  are 
described  by  the  Plan  the  Process  generic  practice  in  each  of  the 
process  areas. 

The  project  may  have  a  hierarchy  of  plans  (e.g.,  risk  mitigation  plans, 
transition  plans,  quality  assurance  plans,  and  configuration 
management  plans).  In  addition,  stakeholder  plans  (e.g.,  operational, 
test,  support,  and  supplier  plans)  must  be  reviewed  to  ensure 
consistency  among  all  project  participants.  This  includes  reviewing 
cross  supplier  dependencies,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Record  of  the  reviews  of  plans  that  affect  the  project 
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SP  3.2  Reconcile  Work  and  Resource  Levels 

Reconcile  the  project  plan  to  reflect  available  and  estimated 
resources. 


To  establish  a  project  that  is  feasible,  obtain  commitment  from  relevant 
stakeholders  and  reconcile  any  differences  between  the  estimates  and 
the  available  resources.  Reconciliation  is  typically  accomplished  by 
lowering  or  deferring  technical  performance  requirements,  negotiating 
more  resources,  finding  ways  to  increase  productivity,  outsourcing, 
adjusting  the  staff  skill  mix,  or  revising  all  plans  that  affect  the  project  or 
schedules. 

During  supplier  selection  and  negotiation  of  the  supplier  agreement,  the 
acquirer  reconciles  overall  project  work  and  resource  levels  based  on 
the  proposals  from  the  supplier.  Following  completion  of  the  supplier 
agreement,  the  acquirer  incorporates  supplier  plans  at  an  appropriate 
level  of  detail  into  the  project  plan  to  support  alignment  of  the  plans.  For 
example,  an  acquirer  may  incorporate  major  supplier  milestones, 
deliverables,  and  reviews,  [acqj 

Typical  Acquirer  Work  Products 

1.  Revised  methods  and  corresponding  estimating  parameters  (e.g., 
better  tools,  use  of  off-the-shelf  components) 

2.  Renegotiated  budgets 

3.  Revised  schedules 

4.  Revised  requirements  list 

5.  Renegotiated  stakeholder  agreements 


SP  3.3  Obtain  Plan  Commitment 

Obtain  commitment  from  relevant  stakeholders  responsible  for 
performing  and  supporting  plan  execution. 


Obtaining  commitment  involves  interaction  among  all  relevant 
stakeholders  both  internal  and  external  to  the  project.  The  individual  or 
group  making  a  commitment  should  have  confidence  that  the  work  can 
be  performed  within  cost,  schedule,  and  performance  constraints. 
Often,  a  provisional  commitment  is  adequate  to  allow  the  effort  to  begin 
and  to  permit  research  to  be  performed  to  increase  confidence  to  the 
appropriate  level  needed  to  obtain  a  full  commitment. 

Typical  Acquirer  Work  Products 

1 .  Documented  requests  for  commitments 

2.  Documented  commitments 
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Subpractices 

1.  Identify  needed  support  and  negotiate  commitments  with  relevant 
stakeholders. 

The  WBS  can  be  used  as  a  checklist  for  ensuring  that  commitments  are  obtained 
for  ail  tasks,  [acqj 

The  plan  for  stakeholder  interaction  should  identify  all  parties  from  whom 
commitment  should  be  obtained,  [acq] 

2.  Document  all  organizational  commitments,  both  full  and 
provisional,  ensuring  appropriate  level  of  signatories. 

Commitments  must  be  documented  to  ensure  a  consistent  mutual  understanding 
as  well  as  for  tracking  and  maintenance.  Provisional  commitments  should  be 
accompanied  by  a  description  of  the  risks  associated  with  the  relationship,  [acq] 

3.  Review  internal  commitments  with  senior  management  as 
appropriate. 

4.  Review  external  commitments  with  senior  management  as 
appropriate. 

Management  may  have  the  necessary  insight  and  authority  to  reduce  risks 
associated  with  external  commitments,  [acqj 

5.  Identify  commitments  on  interfaces  between  elements  in  the 
project,  and  with  other  projects  and  organizational  units  so  that 
they  can  be  monitored. 

Well-defined  interface  specifications  form  the  basis  for  commitments,  [acq] 
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PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Process  and  Product  Quality  Assurance  (PPQA)  is  to 
provide  staff  and  management  with  objective  insight  into  processes  and 
associated  work  products. 


Introductory  Notes 


The  Process  and  Product  Quality  Assurance  process  area  involves  the 
following: 

•  Objectively  evaluating  performed  processes,  work  products,  and 
services  against  the  applicable  process  descriptions,  standards, 
and  procedures 

•  Identifying  and  documenting  noncompliance  issues 

•  Providing  feedback  to  project  staff  and  managers  on  the  results  of 
quality  assurance  activities 

•  Ensuring  that  noncompliance  issues  are  addressed 

The  Process  and  Product  Quality  Assurance  process  area  supports  the 
delivery  of  high-quality  products  and  services  by  providing  the  project 
staff  and  managers  at  all  levels  with  appropriate  visibility  into,  and 
feedback  on,  processes  and  associated  work  products  throughout  the 
life  of  the  project. 

The  acquirer  evaluates  critical  acquirer  work  products,  acquirer 
processes,  results  of  supplier’s  process  quality  assurance  and  supplier 
deliverables.  For  example,  process  and  product  quality  assurance 
ensures  that  the  solicitation  package  was  developed  per  the  standard 
processes  agreed  to  by  the  organization  and  that  it  conforms  to  all 
applicable  policies.  The  acquirer  may  review  the  results  of  the  supplier’s 
quality  assurance  activities  for  selected  supplier  processes  to  ensure 
that  the  supplier  is  following  its  own  processes.  Typically,  selected 
supplier  processes  would  be  critical  processes,  such  as  engineering  or 
verification  processes,  where  the  supplier  is  required  through  the 
supplier  agreement  to  follow  project-specified  standards.  In  exceptional 
cases,  the  acquirer  may  directly  perform  product  and  process  quality 
assurance  for  selected  supplier  processes.  The  acquirer  and  supplier 
periodically  share  quality  assurance  issues  and  findings  that  are  of 
mutual  interest,  [acq] 
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The  practices  in  the  Process  and  Product  Quality  Assurance  process 
area  ensure  that  planned  processes  are  implemented,  while  the 
practices  in  the  Acquisition  Verification  process  area  ensure  that  the 
specified  requirements  are  satisfied.  These  two  process  areas  may  on 
occasion  address  the  same  work  product  but  from  different 
perspectives.  Projects  should  take  advantage  of  the  overlap  in  order  to 
minimize  duplication  of  effort  while  taking  care  to  maintain  the  separate 
perspectives,  [acq] 

Objectivity  in  process  and  product  quality  assurance  evaluations  is 
critical  to  the  success  of  the  project.  (See  the  definition  of  “objectively 
evaluate”  in  the  glossary.)  Objectivity  is  achieved  by  both  independence 
and  the  use  of  criteria.  A  combination  of  methods  providing  evaluations 
against  criteria  by  those  not  producing  the  work  product  is  often  used. 
Less  formal  methods  can  be  used  to  provide  broad  day-to-day 
coverage.  More  formal  methods  can  be  used  periodically  to  assure 
objectivity. 


Examples  of  ways  to  perform  objective  evaluations  include  the  following: 

•  Formal  audits  by  organizationally  separate  quality  assurance  organizations 

•  Peer  reviews  which  may  be  performed  at  various  levels  of  formality 

•  In-depth  review  of  work  at  the  place  it  is  performed  (i.e.,  desk  audits) 

•  Distributed  review  and  comment  of  work  products 


Traditionally,  a  quality  assurance  group  that  is  independent  of  the 
project  provides  this  objectivity.  It  may  be  appropriate  in  some 
organizations,  however,  to  implement  the  process  and  product  quality 
assurance  role  without  that  kind  of  independence.  For  example,  in  an 
organization  with  an  open,  quality-oriented  culture,  the  process  and 
product  quality  assurance  role  may  be  performed,  partially  or 
completely,  by  peers;  and  the  quality  assurance  function  may  be 
embedded  in  the  process.  For  small  organizations,  this  might  be  the 
most  feasible  approach. 

If  quality  assurance  is  embedded  in  the  process,  several  issues  must  be 
addressed  to  ensure  objectivity.  Everyone  performing  quality  assurance 
activities  should  be  trained  in  quality  assurance.  Those  performing 
quality  assurance  activities  for  a  work  product  should  be  separate  from 
those  directly  involved  in  developing  or  maintaining  the  work  product. 

An  independent  reporting  channel  to  the  appropriate  level  of 
organizational  management  must  be  available  so  that  noncompliance 
issues  can  be  escalated  as  necessary. 


282 


Process  and  Product  Quality  Assurance 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


For  example,  in  implementing  peer  reviews  as  an  objective  evaluation  method 

•  Members  are  trained  and  roles  are  assigned  for  people  attending  the  peer  reviews. 

•  Either  (1)  a  member  from  outside  the  project  is  asked  to  attend  the  peer  review 
and  perform  the  role  of  QA,  or  (2)  checklists  are  available  to  support  the  QA 
activity,  and 

•  Defects  are  recorded  as  part  of  the  peer  review  report  and  are  tracked  and 
escalated  outside  the  project  when  necessary. 


Quality  assurance  should  begin  in  the  early  phases  of  a  project  to 
establish  plans,  processes,  standards,  and  procedures  that  will  add 
value  to  the  project  and  satisfy  the  requirements  of  the  project  and  the 
organizational  policies.  Those  performing  quality  assurance  participate 
in  establishing  the  plans,  processes,  standards,  and  procedures  to 
ensure  that  they  fit  the  project’s  needs  and  that  they  will  be  useable  for 
performing  quality  assurance  evaluations.  In  addition,  the  specific 
processes  and  associated  work  products  that  will  be  evaluated  during 
the  project  are  designated.  This  designation  may  be  based  on  sampling 
or  on  objective  criteria  that  are  consistent  with  organizational  policies 
and  project  requirements  and  needs. 

When  noncompliance  issues  are  identified,  they  are  first  addressed 
within  the  project  and  resolved  there  if  possible.  Any  noncompliance 
issues  that  cannot  be  resolved  within  the  project  are  escalated  to  an 
appropriate  level  of  management  for  resolution. 

This  process  area  primarily  applies  to  evaluations  of  products  and 
services,  but  it  also  applies  to  evaluations  of  nonproject  activities  and 
work  products  such  as  training  activities.  For  these  activities  and  work 
products,  the  term  “project”  should  be  appropriately  interpreted. 

It  also  applies  to  the  reviews  of  supplier  process  quality  results  as 
defined  in  the  supplier  agreement.  For  example,  the  supplier  agreement 
can  require  the  supplier  to  provide  detailed  appraisal  results  of 
mandatory,  acquirer-scoped  CMMI  for  Development  appraisals  of 
supplier  processes,  [acq] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  processes  and  associated  work  products  that  will  be 
objectively  evaluated. 

Refer  to  Solicitation  and  Supplier  Agreement  Development  process 
area  for  information  about  specifying  evaluation  of  selected  supplier 
processes  and  work  products,  [acq] 
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Refer  to  Acquisition  Management  process  area  for  information  about 
managing  conformance  to  supplier  agreements,  [acq] 

Refer  to  Acquisition  Verification  process  area  for  information  about 
verification  of  acquirer  work  product  and  supplier  deliverables  such  as 
the  technical  solution,  [acq] 

Specific  Goal  and  Practice  Summary 

SG  1  Objectively  Evaluate  Processes  and  Work  Products 
SP  1.1  Objectively  Evaluate  Processes 
SP  1 .2  Objectively  Evaluate  Work  Products  and  Services 
SG  2  Provide  Objective  Insight 

SP  2.1  Communicate  and  Ensure  Resolution  of 
Noncompliance  Issues 
SP  2.2  Establish  Records 


Specific  Practices  by  Goal 


SG  1  Objectively  Evaluate  Processes  and  Work  Products 

Adherence  of  the  performed  process  and  associated  work  products  and 
services  to  applicable  process  descriptions,  standards,  and  procedures  is 
objectively  evaluated. 


SP  1.1  Objectively  Evaluate  Processes 

Objectively  evaluate  the  designated  performed  processes 
against  the  applicable  process  descriptions,  standards,  and 
procedures. 


Objectivity  in  quality  assurance  evaluations  is  critical  to  the  success  of 
the  project.  A  description  of  the  quality  assurance  reporting  chain  and 
how  it  ensures  objectivity  should  be  defined. 

The  description  of  the  quality  assurance  reporting  chain  is  extended  to 
include  the  relationship  of  the  acquirer  and  suppliers.  It  is  important  to 
ensure  that  acquirer,  and  supplier  processes  comply  with  applicable 
statutory  and  regulatory  requirements,  [acq] 

The  acquirer  evaluates  the  project’s  execution  of  acquirer  processes 
including  interactions  with  suppliers  and  reviews  the  evaluation  reports 
provided  by  suppliers  to  determine  if  they  follow  their  processes.  There 
should  be  sufficient  process  quality  assurance  to  detect  noncompliance 
issues  as  early  as  possible  that  may  affect  the  acquirer’s  or  supplier’s 
ability  to  successfully  deliver  the  products  to  the  customer,  [acq] 

Through  the  supplier  agreement,  the  acquirer  should  retain  the  right  to 
audit  supplier  processes  if  there  is  an  indication  that  suppliers  are  not 
following  acceptable  processes,  [acq] 
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Typical  Acquirer  Work  Products 

1 .  Evaluation  reports 

2.  Noncompliance  reports 

3.  Corrective  actions 

Typical  Supplier  Deliverables 

1 .  Reports  for  evaluations  carried  out  by  supplier [acq] 

2.  Noncompliance  reports  [acq] 

3.  Corrective  actions  [acq] 

Subpractices 

1 .  Promote  an  environment  (created  as  part  of  project  management) 
that  encourages  employee  participation  in  identifying  and  reporting 
quality  issues. 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluations. 

3.  Use  the  stated  criteria  to  evaluate  performed  processes  for 
adherence  to  process  descriptions,  standards,  and  procedures. 

The  supplier  regularly  provides  process  evaluation  reports  as  defined  in  the 
supplier  agreement,  [acq] 

4.  Identify  each  noncompliance  found  during  the  evaluation. 

Analyze  the  results  of  monitoring  the  selected  acquirer  processes  to  detect  issues 
as  early  as  possible  that  may  affect  the  supplier’s  ability  to  satisfy  the 
requirements  of  their  agreement,  [acq] 

5.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services. 


SP  1.2  Objectively  Evaluate  Work  Products  and  Services 

Objectively  evaluate  the  designated  work  products  and 
services  against  the  applicable  process  descriptions, 
standards,  and  procedures. 


In  addition  to  objectively  evaluating  critical  acquirer  work  products,  the 
acquirer  uses  objective  acceptance  criteria  to  evaluate  supplier 
deliverables  throughout  the  project  life  cycle.  For  that,  the  acquirer’s 
acceptance  criteria  for  supplier  deliverables  are  consistent  with  the 
project  objectives  and  sufficient  to  allow  the  supplier  to  satisfactorily 
demonstrate  that  the  product  conforms  to  contractual  requirements,  [acq] 

Refer  to  the  Acquisition  Verification  process  area  for  information  about 
verifying  selected  work  products,  [acq] 
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Typical  Acquirer  Work  Products 

1 .  Evaluation  reports 

2.  Noncompliance  reports 

3.  Corrective  actions 

Subpractices 

1 .  Select  work  products  to  be  evaluated,  based  on  documented 
sampling  criteria  if  sampling  is  used. 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluation  of 
work  products. 

3.  Use  the  stated  criteria  during  the  evaluations  of  work  products. 

4.  Evaluate  work  products  before  they  are  delivered  to  the  customer. 

5.  Evaluate  work  products  at  selected  milestones  in  their 
development. 

6.  Perform  in-progress  or  incremental  evaluations  of  work  products 
and  services  against  process  descriptions,  standards,  and 
procedures. 

7.  Identify  each  case  of  noncompliance  found  during  the  evaluations. 

8.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services. 


SG  2  Provide  Objective  Insight 

Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured. 


SP  2.1  Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 

Communicate  quality  issues  and  ensure  resolution  of 
noncompliance  issues  with  the  staff  and  managers. 


Noncompliance  issues  are  problems  identified  in  evaluations  that  reflect 
a  lack  of  adherence  to  applicable  standards,  process  descriptions,  or 
procedures.  The  status  of  noncompliance  issues  provides  an  indication 
of  quality  trends.  Quality  issues  include  noncompliance  issues  and 
results  of  trend  analysis. 

When  local  resolution  of  noncompliance  issues  cannot  be  obtained,  use 
established  escalation  mechanisms  to  ensure  that  the  appropriate  level 
of  management  can  resolve  the  issue.  Track  noncompliance  issues  to 
resolution. 

Noncompliance  issues  of  both  acquirer  and  supplier  are  tracked  and 
resolved,  [acq] 
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Typical  Acquirer  Work  Products 

1 .  Corrective  action  reports 

2.  Evaluation  reports 

3.  Quality  trends 

4.  Acquirer  feedback  to  suppliers  [acq] 

Typical  Supplier  Deliverables 

1.  Corrective  actions  [acq] 

Subpractices 

1 .  Resolve  each  noncompliance  with  the  appropriate  members  of  the 
staff  where  possible. 

The  acquirer  involves  suppliers  when  resolving  noncompliance  issues,  as 
appropriate,  [acq] 

2.  Document  noncompliance  issues  when  they  cannot  be  resolved 
within  the  project. 


:  Examples  of  ways  to  resolve  noncompliance  within  the  project  include  the 
|  following:  [acq] 

i  •  Fixing  the  noncompliance 

i  •  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 
'  •  Obtaining  a  waiver  to  cover  the  noncompliance  issue 

3.  Escalate  noncompliance  issues  that  cannot  be  resolved  within  the 
project  to  the  appropriate  level  of  management  designated  to 
receive  and  act  on  noncompliance  issues. 

4.  Analyze  the  noncompliance  issues  to  see  if  there  are  any  quality 
trends  that  can  be  identified  and  addressed. 

5.  Ensure  that  relevant  stakeholders  are  aware  of  the  results  of 
evaluations  and  the  quality  trends  in  a  timely  manner. 

6.  Periodically  review  open  noncompliance  issues  and  trends  with  the 
manager  designated  to  receive  and  act  on  noncompliance  issues. 

7.  Track  noncompliance  issues  to  resolution. 

SP  2.2  Establish  Records 

Establish  and  maintain  records  of  the  quality  assurance 

activities. 


Typical  Acquirer  Work  Products 
1.  Evaluation  logs 
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2.  Quality  assurance  reports 

3.  Status  reports  of  corrective  actions 

4.  Reports  of  quality  trends 

Subpractices 

1 .  Record  process  and  product  quality  assurance  activities  in 
sufficient  detail  such  that  status  and  results  are  known. 

2.  Revise  the  status  and  history  of  the  quality  assurance  activities  as 
necessary. 
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QUANTITATIVE  PROJECT  MANAGEMENT 

An  Acquisition  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  the  Quantitative  Project  Management  (QPM)  process 
area  is  to  quantitatively  manage  the  project’s  defined  process  to 
achieve  the  project’s  established  quality  and  process-performance 
objectives. 


Introductory  Notes 


The  Quantitative  Project  Management  process  area  involves  the 

following: 

•  Establishing  and  maintaining  the  project’s  quality  and  process- 
performance  objectives 

•  Identifying  suitable  subprocesses  that  compose  the  project’s 
defined  process  based  on  historical  stability  and  capability  data 
found  in  process  performance  baselines  or  models 

•  Selecting  the  subprocesses  of  the  project’s  defined  process  to  be 
statistically  managed 

•  Monitoring  the  project  to  determine  whether  the  project’s  objectives 
for  quality  and  process  performance  are  being  satisfied,  and 
identifying  appropriate  corrective  action 

•  Selecting  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses 

•  Establishing  and  maintaining  an  understanding  of  the  variation  of 
the  selected  subprocesses  using  the  selected  measures  and 
analytic  techniques 

•  Monitoring  the  performance  of  the  selected  subprocesses  to 
determine  whether  they  are  capable  of  satisfying  their  quality  and 
process-performance  objectives,  and  identifying  corrective  action 

•  Recording  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository 
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The  quality  and  process-performance  objectives,  measures,  and 
baselines  identified  here  are  developed  as  described  in  the 
Organizational  Process  Performance  process  area.  Subsequently,  the 
results  of  performing  the  processes  associated  with  the  Quantitative 
Project  Management  process  area  (e.g.,  measurement  definitions  and 
measurement  data)  become  part  of  the  organizational  process  assets 
referred  to  in  the  Organizational  Process  Performance  process  area. 

To  effectively  address  the  specific  practices  in  this  process  area,  the 
organization  should  have  already  established  a  set  of  standard 
processes  and  related  organizational  process  assets,  such  as  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library  for  use  by  each  project  in  establishing  its  defined  process. 
The  project’s  defined  process  is  a  set  of  subprocesses  that  form  an 
integrated  and  coherent  life  cycle  for  the  project.  It  is  established,  in 
part,  through  selecting  and  tailoring  processes  from  the  organization’s 
set  of  standard  processes.  (See  the  definition  of  “defined  process”  in 
the  glossary.) 

The  project  should  also  ensure  that  the  measurements  and  progress  of 
the  supplier’s  efforts  are  made  available.  Establishment  of  effective 
relationships  with  suppliers  is  necessary  for  the  successful 
implementation  of  this  process  area’s  specific  practices. 

The  acquirer  uses  quantitative  methods  to  manage  the  work  of  the 
acquirer  and  to  gain  insight  into  the  work  and  products  of  the  supplier. 

In  addition  to  its  own  quantitative  data,  the  acquirer  uses  quantitative 
data  provided  by  the  supplier  as  specified  in  the  supplier  agreement  to 
address  the  specific  practices  in  this  process  area,  [acq] 

Process  performance  is  a  measure  of  the  actual  process  results 
achieved.  Process  performance  is  characterized  by  both  process 
measures  (e.g.,  effort,  cycle  time,  and  defect  removal  efficiency)  and 
product  measures  (e.g.,  reliability,  defect  density,  and  response  time). 

Subprocesses  are  defined  components  of  a  larger  defined  process.  The 
subprocesses  themselves  may  be  further  decomposed  as  necessary 
into  other  subprocesses  and  process  elements. 

One  essential  element  of  quantitative  management  is  having 
confidence  in  estimates  (i.e. ,  being  able  to  predict  the  extent  to  which 
the  project  can  fulfill  its  quality  and  process-performance  objectives). 
The  subprocesses  that  will  be  statistically  managed  are  chosen  based 
on  identified  needs  for  predictable  performance.  (See  the  definitions  of 
“statistically  managed  process,”  “quality  and  process-performance 
objective,”  and  “quantitatively  managed  process”  in  the  glossary.) 
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Another  essential  element  of  quantitative  management  is  understanding 
the  nature  and  extent  of  the  variation  experienced  in  process 
performance,  and  recognizing  when  the  project’s  actual  performance 
may  not  be  adequate  to  achieve  the  project’s  quality  and  process- 
performance  objectives. 

Statistical  management  involves  statistical  thinking  and  the  correct  use 
of  a  variety  of  statistical  techniques,  such  as  run  charts,  control  charts, 
confidence  intervals,  prediction  intervals,  and  tests  of  hypotheses. 
Quantitative  management  uses  data  from  statistical  management  to 
help  the  project  predict  whether  it  will  be  able  to  achieve  its  quality  and 
process-performance  objectives  and  identify  what  corrective  action 
should  be  taken. 

This  process  area  applies  to  managing  a  project,  but  the  concepts 
found  here  also  apply  to  managing  other  groups  and  functions.  Applying 
these  concepts  to  managing  other  groups  and  functions  may  not 
necessarily  contribute  to  achieving  the  organization’s  business 
objectives,  but  may  help  these  groups  and  functions  control  their  own 
processes. 


Examples  of  other  groups  and  functions  include  the  following: 

•  Quality  assurance 

•  Process  definition  and  improvement 

•  Effort  reporting 

•  Customer  complaint  handling 

•  Problem  tracking  and  reporting 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives,  specifying  the 
measures  and  analyses  to  be  performed,  obtaining  and  analyzing 
measures,  and  providing  results. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 
performance  objectives,  process  performance  analyses,  process 
performance  baselines,  and  process  performance  models. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  including  the 
organization’s  measurement  repository. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  how  to  identify  the  causes  of  defects  and  other 
problems,  and  taking  action  to  prevent  them  from  occurring  in  the 
future. 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  selecting  and  deploying  improvements  that 
support  the  organization’s  quality  and  process-performance  objectives. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  establishing  the  requirements  for 
supplier  measurements  and  service  levels  in  the  supplier  agreement. 

[ACQ] 


Refer  to  the  Acquisition  Management  process  area  for  more  information 
about  managing  the  service  level  requirements  specified  in  the  supplier 
agreement,  [acq] 

Specific  Goal  and  Practice  Summary 

SG  1  Quantitatively  Manage  the  Project 

SP  1 .1  Establish  the  Project’s  Objectives 
SP  1 .2  Compose  the  Defined  Process 
SP  1 .3  Select  the  Subprocesses  that  Will  Be  Statistically 
Managed 

SP  1 .4  Manage  Project  Performance 
SG  2  Statistically  Manage  Subprocess  Performance 

SP  2.1  Select  Measures  and  Analytic  Techniques 
SP  2.2  Apply  Statistical  Methods  to  Understand  Variation 
SP  2.3  Monitor  Performance  of  the  Selected  Subprocesses 
SP  2.4  Record  Statistical  Management  Data 


Specific  Practices  by  Goal 


SG  1  Quantitatively  Manage  the  Project 

The  project  is  quantitatively  managed  using  quality  and  process- 
performance  objectives. 


SP  1.1  Establish  the  Project’s  Objectives 

Establish  and  maintain  the  project’s  quality  and  process- 
performance  objectives. 
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When  establishing  the  project’s  quality  and  process-performance 
objectives,  it  is  often  useful  to  think  ahead  about  which  processes  from 
the  organization’s  set  of  standard  processes  will  be  included  in  the 
project’s  defined  process,  and  what  the  historical  data  indicates 
regarding  their  process  performance.  These  considerations  will  help  in 
establishing  realistic  objectives  for  the  project.  Later,  as  the  project’s 
actual  performance  becomes  known  and  more  predictable,  the 
objectives  may  need  to  be  revised. 

The  acquirer  establishes  the  project’s  quality  and  process  performance 
objectives  based  on  the  objectives  of  the  organization  and  the  project’s 
objectives.  The  acquirer  may  require  the  supplier  to  provide  process 
performance  measurements  for  their  participation  in  project  processes 
or  subprocesses  (e.g.,  the  estimating  subprocess).  The  acquirer  may 
also  establish  quality  performance  objectives  for  supplier  deliverables. 
These  quantitative  quality  and  process  performance  objectives  for  the 
supplier  are  documented  in  the  supplier  agreement.  The  acquirer 
typically  expects  the  supplier  to  execute  its  processes  and  apply  its 
performance  models  to  meet  the  acquirer’s  quality  performance 
objectives,  [acq] 

Typical  Acquirer  Work  Products 

1 .  The  project’s  quality  and  process-performance  objectives 
Subpractices 

1 .  Review  the  organization's  objectives  for  quality  and  process 
performance. 

The  intent  of  this  review  is  to  ensure  that  the  project  understands  the  broader 
business  context  in  which  the  project  will  need  to  operate.  The  project’s  objectives 
for  quality  and  process  performance  are  developed  in  the  context  of  these 
overarching  organizational  objectives,  [acqj 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 
performance  objectives. 

2.  Identify  the  quality  and  process  performance  needs  and  priorities  of 
the  customer,  suppliers,  end  users,  and  other  relevant 
stakeholders. 


Quantitative  Project  Management 


293 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


:  Examples  of  quality  and  process  performance  attributes  for  which  needs  and 
:  priorities  might  be  identified  include  the  following:  [acqj 

|  •  Functionality 

:  •  Reliability 

i  •  Maintainability 

|  •  Usability 

i  •  Duration 

:  •  Predictability 

:  •  Timeliness 

! 

:  •  Accuracy 


3.  Identify  how  process  performance  is  to  be  measured. 

Consider  whether  the  measures  established  by  the  organization  are  adequate  for 
assessing  progress  in  fulfilling  customer,  end-user,  and  other  stakeholder  needs 
and  priorities.  It  may  be  necessary  to  supplement  these  with  additional  measures. 

[ACQ] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures. 

4.  Define  and  document  measurable  quality  and  process- 
performance  objectives  for  the  project. 

Defining  and  documenting  objectives  for  the  project  involve  the  following:  [acqi 

•  Incorporating  the  organization’s  quality  and  process-performance  objectives 

•  Writing  objectives  that  reflect  the  quality  and  process  performance  needs  and 
priorities  of  the  customer,  end  users,  and  other  stakeholders,  and  the  way  these 
objectives  should  be  measured 

Examples  of  quality  attributes  for  which  objectives  might  be  written  include  the 
:  following:  [acqi 

i  •  Mean  time  between  failures 
|  •  Critical  resource  utilization 
i  •  Number  and  severity  of  defects  in  the  released  product 
:  •  Number  and  severity  of  customer  complaints  concerning  the  provided  service 
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Examples  of  process  performance  attributes  for  which  objectives  might  be  written 
include  the  following:  [acqj 

•  Percentage  of  defects  removed  by  product  verification  activities  (perhaps  by  type 
of  verification,  such  as  peer  reviews  and  testing) 

•  Defect  escape  rates 

•  Number  and  density  of  defects  (by  severity)  found  during  the  first  year  following 
product  delivery  (or  start  of  service) 

•  Cycle  time 

•  Percentage  of  rework  time 


5.  Derive  interim  objectives  for  each  life-cycle  phase,  as  appropriate, 
to  monitor  progress  toward  achieving  the  project’s  objectives. 


An  example  of  a  method  to  predict  future  results  of  a  process  is  the  use  of 
process  performance  models  to  predict  the  latent  defects  in  the  delivered  product 
using  interim  measures  of  defects  identified  during  product  verification  activities 
(e.g.,  peer  reviews  and  testing),  [acqi 


6.  Resolve  conflicts  among  the  project’s  quality  and  process- 
performance  objectives  (e.g.,  if  one  objective  cannot  be  achieved 
without  compromising  another  objective). 

Resolving  conflicts  involves  the  following:  [acqj 

•  Setting  relative  priorities  for  the  objectives 

•  Considering  alternative  objectives  in  light  of  long-term  business  strategies  as  well 
as  short-term  needs 

•  Involving  the  customer,  end  users,  senior  management,  project  management,  and 
other  relevant  stakeholders  in  the  tradeoff  decisions 

•  Revising  the  objectives  as  necessary  to  reflect  the  results  of  the  conflict  resolution 

7.  Establish  traceability  to  the  project’s  quality  and  process- 
performance  objectives  from  their  sources. 


Examples  of  sources  for  objectives  include  the  following:  [acqj 

•  Requirements 

•  Organization’s  quality  and  process-performance  objectives 

•  Customer’s  quality  and  process-performance  objectives 

•  Business  objectives 

•  Discussions  with  customers  and  potential  customers 

•  Market  surveys 
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An  example  of  a  method  to  identify  and  trace  these  needs  and  priorities  is  Quality 
Function  Deployment  (QFD).  [acq] 


8.  Define  and  negotiate  quality  and  process-performance  objectives 
for  suppliers. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development 
process  area  for  more  information  about  incorporating  project 
quality  and  process  performance  objectives  into  solicitation 
packages  and  into  supplier  agreements,  [acq] 

9.  Revise  the  project’s  quality  and  process-performance  objectives  as 
necessary. 


SP  1.2  Compose  the  Defined  Process 

Select  the  subprocesses  that  compose  the  project’s  defined 
process  based  on  historical  stability  and  capability  data. 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  process  asset  library,  which  might 
include  a  process  element  of  known  and  needed  capability. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  process  performance 
baselines  and  process  performance  models. 

Subprocesses  are  identified  from  the  process  elements  in  the 
organization’s  set  of  standard  processes  and  the  process  artifacts  in  the 
organization’s  process  asset  library. 

These  subprocesses  may  include  subprocesses  for  interacting  with  a 
supplier  (e.g.,  negotiating  a  supplier  agreement  and  conducting  supplier 
reviews),  [acq] 

Typical  Acquirer  Work  Products 

1.  Criteria  used  in  identifying  which  subprocesses  are  valid 
candidates  for  inclusion  in  the  project’s  defined  process 

2.  Candidate  subprocesses  for  inclusion  in  the  project’s  defined 
process 

3.  Subprocesses  to  be  included  in  the  project’s  defined  process 

4.  Identified  risks  when  selected  subprocesses  lack  a  process 
performance  history 
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Subpractices 

1 .  Establish  the  criteria  to  use  in  identifying  which  subprocesses  are 
valid  candidates  for  use. 

Identification  may  be  based  on  the  following:  [acqi 

•  Quality  and  process-performance  objectives 

•  Existence  of  process  performance  data 

•  Product  line  standards 

•  Project  life-cycle  models 

•  Customer  requirements 

•  Laws  and  regulations 

2.  Determine  whether  the  subprocesses  that  are  to  be  statistically 
managed,  and  that  were  obtained  from  the  organizational  process 
assets,  are  suitable  for  statistical  management. 

A  subprocess  may  be  more  suitable  for  statistical  management  if  it  has  a  history 
of  the  following:  [acqi 

•  Stable  performance  in  previous  comparable  instances 

•  Process  performance  data  that  satisfies  the  project’s  quality  and  process- 
performance  objectives 

Historical  data  are  primarily  obtained  from  the  organization’s  process  performance 
baselines.  However,  these  data  may  not  be  available  for  all  subprocesses,  [acqi 

3.  Analyze  the  interaction  of  subprocesses  to  understand  the 
relationships  among  the  subprocesses  and  the  measured  attributes 
of  the  subprocesses. 


Examples  of  analysis  techniques  include  system  dynamics  models  and 
;  simulations,  [acqi 


4.  Identify  the  risk  when  no  subprocess  is  available  that  is  known  to 
be  capable  of  satisfying  the  quality  and  process-performance 
objectives  (i.e.,  no  capable  subprocess  is  available  or  the  capability 
of  the  subprocess  is  not  known). 

Even  when  a  subprocess  has  not  been  selected  to  be  statistically  managed, 
historical  data  and  process  performance  models  may  indicate  that  the  subprocess 
is  not  capable  of  satisfying  the  quality  and  process-performance  objectives,  [acqi 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  risk  identification  and  analysis. 
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SP  1.3  Select  the  Subprocesses  that  Will  Be  Statistically  Managed 

Select  the  subprocesses  of  the  project's  defined  process  that 
will  be  statistically  managed. 


Selecting  the  subprocesses  to  be  statistically  managed  is  often  a 
concurrent  and  iterative  process  of  identifying  applicable  project  and 
organization  quality  and  process-performance  objectives,  selecting  the 
subprocesses,  and  identifying  the  process  and  product  attributes  to 
measure  and  control.  Often  the  selection  of  a  process,  quality  and 
process-performance  objective,  or  measurable  attribute  will  constrain 
the  selection  of  the  other  two.  For  example,  if  a  particular  process  is 
selected,  the  measurable  attributes  and  quality  and  process- 
performance  objectives  may  be  constrained  by  that  process. 

Typical  Acquirer  Work  Products 

1 .  Quality  and  process-performance  objectives  that  will  be  addressed 
by  statistical  management 

2.  Criteria  used  in  selecting  which  subprocesses  will  be  statistically 
managed 

3.  Subprocesses  that  will  be  statistically  managed 

4.  Identified  process  and  product  attributes  of  the  selected 
subprocesses  that  should  be  measured  and  controlled 

Subpractices 

1 .  Identify  which  of  the  quality  and  process-performance  objectives  of 
the  project  will  be  statistically  managed. 

2.  Identify  the  criteria  to  be  used  in  selecting  the  subprocesses  that 
are  the  main  contributors  to  achieving  the  identified  quality  and 
process-performance  objectives  and  for  which  predictable 
performance  is  important. 


Examples  of  sources  for  criteria  used  in  selecting  subprocesses  include  the 
following:  [acqi 

•  Customer  requirements  related  to  quality  and  process  performance 

•  Quality  and  process-performance  objectives  established  by  the  customer 

•  Quality  and  process-performance  objectives  established  by  the  organization 

•  Organization’s  performance  baselines  and  models 

•  Stable  performance  of  the  subprocess  on  other  projects 

•  Laws  and  regulations 


3.  Select  the  subprocesses  that  will  be  statistically  managed  using  the 
selection  criteria. 
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It  may  not  be  possible  to  statistically  manage  some  subprocesses  (e.g.,  where 
new  subprocesses  and  technologies  are  being  piloted),  in  other  cases,  it  may  not 
be  economically  justifiable  to  apply  statistical  techniques  to  certain  subprocesses. 

[ACQ] 

4.  Identify  the  product  and  process  attributes  of  the  selected 
subprocesses  that  will  be  measured  and  controlled. 


Examples  of  product  and  process  attributes  include  the  following:  [acq] 

•  Defect  density 

•  Cycle  time 

•  Test  coverage 


Refer  to  the  Solicitation  and  Supplier  Agreement  Development 
process  area  for  more  information  about  establishing  requirements 
for  statistical  management  and  reporting  of  supplier  subprocesses 
in  the  supplier  agreement,  [acqj 


SP  1.4  Manage  Project  Performance 

Monitor  the  project  to  determine  whether  the  project’s 
objectives  for  quality  and  process  performance  will  be 
satisfied,  and  identify  corrective  action  as  appropriate. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  and  using  measures. 

A  prerequisite  for  such  a  comparison  is  that  the  selected  subprocesses 
of  the  project’s  defined  process  are  being  statistically  managed  and 
their  process  capability  is  understood.  The  specific  practices  of  specific 
goal  2  provide  detail  on  statistically  managing  the  selected 
subprocesses. 

The  acquirer  monitors  the  performance  of  selected  subprocesses, 
including  those  that  involve  interaction  with  a  supplier,  as  well  as  the 
quality  and  performance  of  the  supplier  deliverables,  for  adherence  to 
the  quality  and  performance  objectives.  This  selective  monitoring 
provides  the  acquirer  with  insight  into  project  and  supplier  performance 
in  order  to  predict  the  likelihood  of  achieving  the  project’s  objectives  for 
quality  and  process  performance.  The  acquirer  uses  this  information  to 
manage  the  risks  of  the  project  and  to  initiate  corrective  actions  in  time 
to  meet  the  project  objectives,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Estimates  (predictions)  of  the  achievement  of  the  project’s  quality 
and  process-performance  objectives 

2.  Documentation  of  the  risks  in  achieving  the  project’s  quality  and 
process-performance  objectives 
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3.  Documentation  of  actions  needed  to  address  the  deficiencies  in 
achieving  the  project’s  objectives 

Typical  Supplier  Deliverables 

1 .  Supplier  estimates  (predictions)  of  the  achievement  of  the  project’s 
quality  and  process-performance  objectives  [acqi 

2.  Documentation  of  the  supplier  risks  in  achieving  the  project’s 
quality  and  process-performance  objectives  [acqi 

3.  Documentation  of  actions  needed  to  address  the  deficiencies  in 
achieving  the  project’s  objectives  [acq] 

Subpractices 

1 .  Periodically  review  the  performance  of  each  subprocess  and  the 
capability  of  each  subprocess  selected  to  be  statistically  managed 
to  appraise  progress  toward  achieving  the  project’s  quality  and 
process-performance  objectives. 

The  process  capability  of  each  selected  subprocess  is  determined  with  respect  to 
that  subprocess’  established  quality  and  process-performance  objectives.  These 
objectives  are  derived  from  the  project’s  quality  and  process-performance 
objectives,  which  are  for  the  project  as  a  whole,  [acqi 

2.  Periodically  review  the  actual  results  achieved  against  established 
interim  objectives  for  each  phase  of  the  project  life  cycle  to 
appraise  progress  toward  achieving  the  project’s  quality  and 
process-performance  objectives. 

3.  Track  suppliers’  results  for  achieving  their  quality  and  process- 
performance  objectives. 

4.  Use  process  performance  models  calibrated  with  obtained 
measures  of  critical  attributes  to  estimate  progress  toward 
achieving  the  project’s  quality  and  process-performance  objectives. 

Process  performance  models  are  used  to  estimate  progress  toward  achieving 
objectives  that  cannot  be  measured  until  a  future  phase  in  the  project  life  cycle. 

An  example  is  the  use  of  process  performance  models  to  predict  the  latent 
defects  in  the  delivered  product  using  interim  measures  of  defects  identified 
during  peer  reviews,  [acqi 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

The  calibration  is  based  on  the  results  obtained  from  performing  the  previous 
subpractices,  [acq] 

5.  Identify  and  manage  the  risks  associated  with  achieving  the 
project’s  quality  and  process-performance  objectives. 
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Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks. 


Example  sources  of  the  risks  include  the  following:  [acqi 

•  Inadequate  stability  and  capability  data  in  the  organization’s  measurement 
repository 

•  Subprocesses  having  inadequate  performance  or  capability 

•  Suppliers  not  achieving  their  quality  and  process-performance  objectives 

•  Lack  of  visibility  into  supplier  capability 

•  Inaccuracies  in  the  organization’s  process  performance  models  for  predicting 
future  performance 

•  Deficiencies  in  predicted  process  performance  (estimated  progress) 

•  Other  identified  risks  associated  with  identified  deficiencies 


6.  Determine  and  document  actions  needed  to  address  the 
deficiencies  in  achieving  the  project’s  quality  and  process- 
performance  objectives. 

The  intent  of  these  actions  is  to  plan  and  deploy  the  right  set  of  activities, 
resources,  and  schedule  to  place  the  project  back  on  track  as  much  as  possible  to 
meet  its  objectives,  [acqj 


Examples  of  actions  that  can  be  taken  to  address  deficiencies  in  achieving  the 

project’s  objectives  include  the  following:  [acqj 

•  Changing  quality  or  process-performance  objectives  so  that  they  are  within  the 
expected  range  of  the  project’s  defined  process 

•  Improving  the  implementation  of  the  project’s  defined  process  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  project’s  performance  within 
the  objectives  without  having  to  move  the  mean) 

•  Adopting  new  subprocesses  and  technologies  that  have  the  potential  for  satisfying 
the  objectives  and  managing  the  associated  risks 

•  Identifying  the  risk  and  risk  mitigation  strategies  for  the  deficiencies 

•  Terminating  the  project 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 
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SG  2  Statistically  Manage  Subprocess  Performance 

The  performance  of  selected  subprocesses  within  the  project's  defined 
process  is  statistically  managed. 

This  specific  goal  describes  an  activity  critical  to  achieving  the 
Quantitatively  Manage  the  Project  specific  goal  of  this  process  area. 
The  specific  practices  under  this  specific  goal  describe  how  to 
statistically  manage  the  subprocesses  whose  selection  was  described 
in  the  specific  practices  under  the  first  specific  goal.  When  the  selected 
subprocesses  are  statistically  managed,  their  capability  to  achieve  their 
objectives  can  be  determined.  By  these  means,  it  will  be  possible  to 
predict  whether  the  project  will  be  able  to  achieve  its  objectives,  which 
is  key  to  quantitatively  managing  the  project. 


SP  2.1  Select  Measures  and  Analytic  Techniques 

Select  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives;  on  defining, 
collecting,  and  analyzing  measures;  and  on  revising  measures  and 
statistical  analysis  techniques. 

Typical  Acquirer  Work  Products 

1 .  Definitions  of  the  measures  and  analytic  techniques  to  be  used  in 
(or  proposed  for)  statistically  managing  the  subprocesses 

2.  Operational  definitions  of  the  measures,  their  collection  points  in 
the  subprocesses,  and  how  the  integrity  of  the  measures  will  be 
determined 

3.  Traceability  of  measures  back  to  the  project’s  quality  and  process- 
performance  objectives 

4.  Instrumented  organizational  support  environment  to  support 
automatic  data  collection 

Subpractices 

1 .  Identify  common  measures  from  the  organizational  process  assets 
that  support  statistical  management. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  common  measures. 

Product  lines  or  other  stratification  criteria  may  categorize  common  measures,  [acqj 

2.  Identify  additional  measures  that  may  be  needed  for  this  instance 
to  cover  critical  product  and  process  attributes  of  the  selected 
subprocesses. 
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In  some  cases,  measures  may  be  research  oriented.  Such  measures  should  be 
explicitly  identified,  [acq] 

3.  Identify  the  measures  that  are  appropriate  for  statistical 
management. 

Critical  criteria  for  selecting  statistical  management  measures  include  the 
following:  [acqi 

•  Controllable  (e.g.,  can  a  measure’s  values  be  changed  by  changing  how  the 
subprocess  is  implemented?) 

•  Adequate  performance  indicator  (e.g.,  is  the  measure  a  good  indicator  of  how  well 
the  subprocess  is  performing  relative  to  the  objectives  of  interest?) 


Examples  of  subprocess  measures  include  the  following:  [acq] 

•  Requirements  volatility 

•  Ratios  of  estimated  to  measured  values  of  the  planning  parameters  (e.g.,  size, 
cost,  and  schedule) 

•  Coverage  and  efficiency  of  peer  reviews 

•  Test  coverage  and  efficiency 

•  Effectiveness  of  training  (e.g.,  percent  of  planned  training  completed  and  test 
scores) 

•  Reliability 

•  Percentage  of  the  total  defects  inserted  or  found  in  the  different  phases  of  the 
project  life  cycle 

•  Percentage  of  the  total  effort  expended  in  the  different  phases  of  the  project  life 
cycle 


4.  Specify  the  operational  definitions  of  the  measures,  their  collection 
points  in  the  subprocesses,  and  how  the  integrity  of  the  measures 
will  be  determined. 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows:  [acqj 

•  Communication:  What  has  been  measured,  how  it  was  measured,  what  the  units 
of  measure  are,  and  what  has  been  included  or  excluded 

•  Repeatability:  Whether  the  measurement  can  be  repeated,  given  the  same 
definition,  to  get  the  same  results 

5.  Analyze  the  relationship  of  the  identified  measures  to  the 
organization’s  and  project’s  objectives,  and  derive  objectives  that 
state  specific  target  measures  or  ranges  to  be  met  for  each 
measured  attribute  of  each  selected  subprocess. 

6.  Instrument  the  organizational  support  environment  to  support 
collection,  derivation,  and  analysis  of  statistical  measures. 
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The  instrumentation  is  based  on  the  following:  [acqi 

•  Description  of  the  organization’s  set  of  standard  processes 

•  Description  of  the  project’s  defined  process 

•  Capabilities  of  the  organizational  support  environment 

7.  Identify  the  appropriate  statistical  analysis  techniques  that  are 
expected  to  be  useful  in  statistically  managing  the  selected 
subprocesses. 

The  concept  of  “one  size  does  not  fit  all"  applies  to  statistical  analysis  techniques. 
What  makes  a  particular  technique  appropriate  is  not  just  the  type  of  measures, 
but  more  important,  how  the  measures  will  be  used  and  whether  the  situation 
warrants  applying  that  technique.  The  appropriateness  of  the  selection  may  need 
to  be  investigated  from  time  to  time,  [acqi 

Examples  of  statistical  analysis  techniques  are  given  in  the  next  specific  practice. 

[ACQ] 

8.  Revise  the  measures  and  statistical  analysis  techniques  as 
necessary. 


SP  2.2  Apply  Statistical  Methods  to  Understand  Variation 

Establish  and  maintain  an  understanding  of  the  variation  of  the 
selected  subprocesses  using  the  selected  measures  and 
analytic  techniques. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting,  analyzing,  and  using  measurement  results. 

Understanding  variation  is  achieved,  in  part,  by  collecting  and  analyzing 
process  and  product  measures  so  that  special  causes  of  variation  can 
be  identified  and  addressed  to  achieve  predictable  performance. 

A  special  cause  of  process  variation  is  characterized  by  an  unexpected 
change  in  process  performance.  Special  causes  are  also  known  as 
“assignable  causes”  because  they  can  be  identified,  analyzed,  and 
addressed  to  prevent  recurrence. 

The  identification  of  special  causes  of  variation  is  based  on  departures 
from  the  system  of  common  causes  of  variation.  These  departures  can 
be  identified  by  the  presence  of  extreme  values,  or  other  identifiable 
patterns  in  the  data  collected  from  the  subprocess  or  associated  work 
products.  Knowledge  of  variation  and  insight  about  potential  sources  of 
anomalous  patterns  are  typically  needed  to  detect  special  causes  of 
variation. 
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Sources  of  anomalous  patterns  of  variation  may  include  the  following: 

•  Lack  of  process  compliance 

•  Undistinguished  influences  of  multiple  underlying  subprocesses  on  the  data 

•  Ordering  or  timing  of  activities  within  the  subprocess 

•  Uncontrolled  inputs  to  the  subprocess 

•  Environmental  changes  during  subprocess  execution 

•  Schedule  pressure 

•  Inappropriate  sampling  or  grouping  of  data 


Typical  Acquirer  Work  Products 

1.  Collected  measures 

2.  Natural  bounds  of  process  performance  for  each  measured 
attribute  of  each  selected  subprocess 

3.  Process  performance  compared  to  the  natural  bounds  of  process 
performance  for  each  measured  attribute  of  each  selected 
subprocess 

Typical  Supplier  Deliverables 

1 .  Collected  supplier  measures  [acq] 

2.  Natural  bounds  of  supplier  process  performance  for  each 
measured  attribute  of  each  selected  subprocess  [acq] 

3.  Supplier  process  performance  compared  to  the  natural  bounds  of 
process  performance  for  each  measured  attribute  of  each  selected 
subprocess  [acq] 

Subpractices 

1 .  Establish  trial  natural  bounds  for  subprocesses  having  suitable 
historical  performance  data. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  organizational  process  performance 
baselines. 

Natural  bounds  of  an  attribute  are  the  range  within  which  variation  normally 
occurs.  All  processes  will  show  some  variation  in  process  and  product  measures 
each  time  they  are  executed.  The  issue  is  whether  this  variation  is  due  to  common 
causes  of  variation  in  the  normal  performance  of  the  process  or  to  some  special 
cause  that  can  and  should  be  identified  and  removed. 
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When  a  subprocess  is  initially  executed,  suitable  data  for  establishing  trial  natural 
bounds  are  sometimes  available  from  prior  instances  of  the  subprocess  or 
comparable  subprocesses,  process  performance  baselines,  or  process 
performance  models.  These  data  are  typically  contained  in  the  organization’s 
measurement  repository.  As  the  subprocess  is  executed,  data  specific  to  that 
instance  are  collected  and  used  to  update  and  replace  the  trial  natural  bounds. 
However,  if  the  subprocess  in  question  has  been  materially  tailored,  or  if  the 
conditions  are  materially  different  from  those  in  previous  instantiations,  the  data  in 
the  repository  may  not  be  relevant  and  should  not  be  used. 

In  some  cases,  there  may  be  no  historical  comparable  data  (e.g.,  when 
introducing  a  new  subprocess,  when  entering  a  new  application  domain,  or  when 
significant  changes  have  been  made  to  the  subprocess).  In  such  cases,  trial 
natural  bounds  will  have  to  be  made  from  early  process  data  of  this  subprocess. 
These  trial  natural  bounds  must  then  be  refined  and  updated  as  subprocess 
execution  continues. 


Examples  of  criteria  for  determining  whether  data  are  comparable  include  the 
following:  [acqi 

•  Product  lines 

•  Application  domain 

•  Work  product  and  task  attributes  (e.g.,  size  of  product) 

•  Size  of  project 


2.  Collect  data,  as  defined  by  the  selected  measures,  on  the 
subprocesses  as  they  execute. 

3.  Calculate  the  natural  bounds  of  process  performance  for  each 
measured  attribute. 


Examples  of  where  the  natural  bounds  are  calculated  include  the  following:  [acqj 

•  Control  charts 

•  Confidence  intervals  (for  parameters  of  distributions) 

•  Prediction  intervals  (for  future  outcomes) 


4.  Identify  special  causes  of  variation. 


An  example  of  a  criterion  for  detecting  a  special  cause  of  process  variation  in  a 
control  chart  is  a  data  point  that  falls  outside  of  the  3-sigma  control  limits,  [acqi 


The  criteria  for  detecting  special  causes  of  variation  are  based  on  statistical  theory 
and  experience  and  depend  on  economic  justification.  As  criteria  are  added, 
special  causes  are  more  likely  to  be  identified  if  present,  but  the  likelihood  of  false 
alarms  also  increases,  [acqi 
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5.  Analyze  the  special  cause  of  process  variation  to  determine  the 
reasons  the  anomaly  occurred. 


Examples  of  techniques  for  analyzing  the  reasons  for  special  causes  of  variation 
include  the  following:  [acqj 

•  Cause-and-effect  (fishbone)  diagrams 

•  Designed  experiments 

•  Control  charts  (applied  to  subprocess  inputs  or  to  lower  level  subprocesses) 

•  Subgrouping  (analyzing  the  same  data  segregated  into  smaller  groups  based  on 
an  understanding  of  how  the  subprocess  was  implemented  facilitates  isolation  of 
special  causes) 


Some  anomalies  may  simply  be  extremes  of  the  underlying  distribution  rather 
than  problems.  The  people  implementing  a  subprocess  are  usually  the  ones  best 
able  to  analyze  and  understand  special  causes  of  variation,  [acqj 

6.  Determine  what  corrective  action  should  be  taken  when  special 
causes  of  variation  are  identified. 

Removing  a  special  cause  of  process  variation  does  not  change  the  underlying 
subprocess.  It  addresses  an  error  in  the  way  the  subprocess  is  being  executed. 

[ACQ] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

7.  Recalculate  the  natural  bounds  for  each  measured  attribute  of  the 
selected  subprocesses  as  necessary. 

Recalculating  the  (statistically  estimated)  natural  bounds  is  based  on  measured 
values  that  signify  that  the  subprocess  has  changed,  not  on  expectations  or 
arbitrary  decisions,  [acqj 


Examples  of  when  the  natural  bounds  may  need  to  be  recalculated  include  the 
following:  [acqj 

•  There  are  incremental  improvements  to  the  subprocess 

•  New  tools  are  deployed  for  the  subprocess 

•  A  new  subprocess  is  deployed 

•  The  collected  measures  suggest  that  the  subprocess  mean  has  permanently 
shifted  or  the  subprocess  variation  has  permanently  changed 


SP  2.3  Monitor  Performance  of  the  Selected  Subprocesses 

Monitor  the  performance  of  the  selected  subprocesses  to 
determine  their  capability  to  satisfy  their  quality  and  process- 
performance  objectives,  and  identify  corrective  action  as 
necessary. 
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The  intent  of  this  specific  practice  is  to  do  the  following: 

•  Determine  statistically  the  process  behavior  expected  from  the 
subprocess 

•  Appraise  the  probability  that  the  process  will  meet  its  quality  and 
process-performance  objectives 

•  Identify  the  corrective  action  to  be  taken,  based  on  a  statistical 
analysis  of  the  process  performance  data 

Corrective  action  may  include  renegotiating  the  affected  project 
objectives,  identifying  and  implementing  alternative  subprocesses,  or 
identifying  and  measuring  lower  level  subprocesses  to  achieve  greater 
detail  in  the  performance  data.  Any  or  all  of  these  actions  are  intended 
to  help  the  project  use  a  more  capable  process.  (See  the  definition  of 
“capable  process”  in  the  glossary.) 

A  prerequisite  for  comparing  the  capability  of  a  selected  subprocess 
against  its  quality  and  process-performance  objectives  is  that  the 
performance  of  the  subprocess  is  stable  and  predictable  with  respect  to 
its  measured  attributes. 

Process  capability  is  analyzed  for  those  subprocesses  and  those 
measured  attributes  for  which  (derived)  objectives  have  been 
established.  Not  all  subprocesses  or  measured  attributes  that  are 
statistically  managed  are  analyzed  regarding  process  capability. 

The  historical  data  may  be  inadequate  for  initially  determining  whether 
the  subprocess  is  capable.  It  also  is  possible  that  the  estimated  natural 
bounds  for  subprocess  performance  may  shift  away  from  the  quality 
and  process-performance  objectives.  In  either  case,  statistical  control 
implies  monitoring  capability  as  well  as  stability. 

Typical  Acquirer  Work  Products 

1 .  Natural  bounds  of  process  performance  for  each  selected 
subprocess  compared  to  its  established  (derived)  objectives 

2.  For  each  subprocess,  its  process  capability 

3.  For  each  subprocess,  the  actions  needed  to  address  deficiencies 
in  its  process  capability 

Typical  Supplier  Deliverables 

1 .  Actions  needed  to  address  deficiencies  in  supplier  process 

performance  measures  or  quality  measures  for  deliverables  [acq] 

Subpractices 

1 .  Compare  the  quality  and  process-performance  objectives  to  the 
natural  bounds  of  the  measured  attribute. 


308 


Quantitative  Project  Management 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


This  comparison  provides  an  appraisal  of  the  process  capability  for  each 
measured  attribute  of  a  subprocess.  These  comparisons  can  be  displayed 
graphically,  in  ways  that  relate  the  estimated  natural  bounds  to  the  objectives  or 
as  process  capability  indices,  which  summarize  the  relationship  of  the  objectives 
to  the  natural  bounds,  [acqi 

2.  Monitor  changes  in  quality  and  process-performance  objectives 
and  selected  subprocess’  process  capability. 

3.  Identify  and  document  subprocess  capability  deficiencies. 

4.  Determine  and  document  actions  needed  to  address  subprocess 
capability  deficiencies. 


Examples  of  actions  that  can  be  taken  when  a  selected  subprocess’s 

performance  does  not  satisfy  its  objectives  include  the  following:  [acqi 

•  Changing  quality  and  process-performance  objectives  so  that  they  are  within  the 
subprocess’  process  capability 

•  Improving  the  implementation  of  the  existing  subprocess  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  natural  bounds  within  the 
objectives  without  having  to  move  the  mean) 

•  Adopting  new  process  elements  and  subprocesses  and  technologies  that  have 
the  potential  for  satisfying  the  objectives  and  managing  the  associated  risks 

•  Identifying  risks  and  risk  mitigation  strategies  for  each  subprocess’s  process 
capability  deficiency 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 


SP  2.4  Record  Statistical  Management  Data 

Record  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository. 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  managing  and  storing  data,  measurement  definitions, 
and  results. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository. 

Typical  Acquirer  Work  Products 

1 .  Statistical  and  quality  management  data  recorded  in  the 
organization’s  measurement  repository 
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REQUIREMENTS  MANAGEMENT 


An  Project  Management  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Requirements  Management  (REQM)  is  to  manage  the 
requirements  of  the  project’s  products  and  product  components  and  to 
identify  inconsistencies  between  those  requirements  and  the  project’s 
plans  and  work  products. 


Introductory  Notes 


Requirements  management  processes  manage  all  requirements 
received  or  generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements  levied  on  the 
project  by  the  organization.  In  particular,  if  the  Acquisition  Requirements 
Development  process  area  is  implemented,  its  processes  will  generate 
customer  and  contractual  requirements  that  will  also  be  managed  by 
the  requirements  management  processes.  Throughout  the  process 
areas,  where  we  use  the  terms  product  and  product  component,  they 
are  intended  to  include  service  and  service  component  and  should  be 
interpreted  in  that  way.  When  the  Requirements  Management, 
Acquisition  Requirements  Development,  and  Acquisition  Technical 
Solution  process  areas  are  all  implemented,  their  associated  processes 
may  be  closely  tied  and  be  performed  concurrently,  [acq] 

The  project  takes  appropriate  steps  to  ensure  that  the  agreed-on  set  of 
requirements  is  managed  to  support  the  planning  and  execution  needs 
of  the  project.  When  a  project  receives  requirements  from  an  approved 
requirements  provider,  the  requirements  are  reviewed  with  the 
requirements  provider  to  resolve  issues  and  prevent  misunderstanding 
before  the  requirements  are  incorporated  into  the  project’s  plans.  Once 
the  requirements  provider  and  the  requirements  receiver  reach  an 
agreement,  commitment  to  the  requirements  is  obtained  from  the 
project  participants.  The  project  manages  changes  to  the  requirements 
as  they  evolve  and  identifies  any  inconsistencies  that  occur  among  the 
plans,  work  products,  and  requirements. 

Part  of  the  management  of  requirements  is  to  document  requirements 
changes  and  rationale  and  to  maintain  bidirectional  traceability  between 
source  requirements  and  all  product  and  product-component 
requirements.  (See  the  definition  of  “bidirectional  traceability”  in  the 
glossary.). 
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All  projects  have  requirements.  In  the  case  of  a  project  that  is  focused 
on  maintenance  activities,  the  changes  to  the  product  or  product 
components  are  based  on  changes  to  the  existing  requirements, 
design,  or  implementation.  The  requirements  changes,  if  any,  might  be 
documented  in  change  requests  from  the  customer  or  users,  or  they 
might  take  the  form  of  new  requirements  received  from  the 
requirements  development  process.  Regardless  of  their  source  or  form, 
the  maintenance  activities  that  are  driven  by  changes  to  requirements 
are  managed  accordingly. 


Related  Process  Areas 


Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  transforming  stakeholder  intentions  into 
customer  requirements  and  deciding  how  to  allocate  or  distribute 
requirements  among  the  suppliers  and  their  deliverables,  [acq] 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  design  constraints,  [acq] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
how  project  plans  reflect  requirements  and  need  to  be  revised  as 
requirements  change. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  baselines  and  controlling  changes  to  configuration 
documentation  for  requirements. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  and  controlling  the  activities  and  work 
products  that  are  based  on  the  requirements  and  taking  appropriate 
corrective  action. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  handling  risks  associated  with  requirements. 
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Specific  Goal  and  Practice  Summary 


SG  1  Manage  Requirements 

SP  1.1  Obtain  an  Understanding  of  Requirements 
SP  1 .2  Obtain  Commitment  to  Requirements 

SP1.3  Manage  Requirements  Changes 

SP  1.4  Maintain  Bidirectional  Traceability  of  Requirements 
SP  1 .5  Identify  Inconsistencies  between  Project  Work  and 
Requirements 


Specific  Practices  by  Goal 


SG  1  Manage  Requirements 

Requirements  are  managed  and  inconsistencies  with  project  plans  and 
work  products  are  identified. 

The  project  maintains  a  current  and  approved  set  of  requirements  over 
the  life  of  the  project  by  doing  the  following: 

•  Managing  all  changes  to  the  requirements 

•  Maintaining  the  relationships  among  the  requirements,  the  project 
plans,  and  the  work  products 

•  Identifying  inconsistencies  among  the  requirements,  the  project 
plans,  and  the  work  products 

•  Taking  corrective  action 

This  typically  includes  directly  managing  changes  to  customer  and 
contractual  requirements  developed  by  acquirer  and  oversight  of  the 
supplier’s  requirements  management  process.  Requirements  changes 
may  result  in  changes  to  the  supplier  agreement,  [acqi 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

SP  1.1  Obtain  an  Understanding  of  Requirements 

Develop  an  understanding  with  the  requirements  providers  on 
the  meaning  of  the  requirements. 


As  the  project  matures  and  requirements  are  derived,  all  activities  or 
disciplines  will  receive  requirements.  To  avoid  requirements  creep, 
criteria  are  established  to  designate  appropriate  channels,  or  official 
sources,  from  which  to  receive  requirements.  The  receiving  activities 
conduct  analyses  of  the  requirements  with  the  requirements  provider  to 
ensure  that  a  compatible,  shared  understanding  is  reached  on  the 
meaning  of  the  requirements.  The  result  of  this  analysis  and  dialog  is  an 
agreed-to  set  of  requirements. 
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Typical  Acquirer  Work  Products 

1 .  Lists  of  criteria  for  distinguishing  appropriate  requirements 
providers 

2.  Criteria  for  evaluation  and  acceptance  of  requirements 

3.  Results  of  analyses  against  criteria 

4.  An  agreed-to  set  of  requirements 

Subpractices 

1 .  Establish  criteria  for  distinguishing  appropriate  requirements 
providers. 

2.  Establish  objective  criteria  for  the  evaluation  and  acceptance  of 
requirements. 

Lack  of  evaluation  and  acceptance  criteria  often  results  in  inadequate  verification, 
costly  rework,  or  customer  rejection,  [acq] 

Examples  of  evaluation  and  acceptance  criteria  include  the  following:  [acqi 

i  •  Clearly  and  properly  stated 
i  •  Complete 

|  •  Consistent  with  each  other 
:  •  Uniquely  identified 
i  •  Appropriate  to  implement 
j  •  Verifiable  (testable) 

:  •  Traceable 

3.  Analyze  requirements  to  ensure  that  the  established  criteria  are 
met. 

4.  Reach  an  understanding  of  the  requirements  with  the  requirements 
provider  so  that  the  project  participants  can  commit  to  them. 

SP  1.2  Obtain  Commitment  to  Requirements 

Obtain  commitment  to  the  requirements  from  the  project 
participants. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  the  commitments  made. 
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Whereas  the  previous  specific  practice  dealt  with  reaching  an 
understanding  with  the  requirements  providers,  this  specific  practice 
deals  with  agreements  and  commitments  among  those  who  have  to 
carry  out  the  activities  necessary  to  implement  the  requirements. 
Requirements  evolve  throughout  the  project,  especially  as  described  by 
the  specific  practices  of  the  Acquisition  Requirements  Development 
process  area  and  the  Acquisition  Technical  Solution  process  area.  As 
the  requirements  evolve,  this  specific  practice  ensures  that  project 
participants  commit  to  the  current,  approved  requirements  and  the 
resulting  changes  in  project  plans,  activities,  and  work  products,  [acq] 

Changes  to  requirements  may  lead  to  changes  in  supplier  agreements; 
these  changes  need  to  be  agreed  upon  between  the  project  and  the 
supplier  after  appropriate  negotiations,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Requirements  impact  assessments 

2.  Documented  commitments  to  requirements  and  requirements 
changes 

Typical  Supplier  Deliverables 

1 .  Supplier’s  requirements  impact  assessments  [acq] 

Subpractices 

1 .  Assess  the  impact  of  requirements  on  existing  commitments. 

2.  Negotiate  and  record  commitments. 

Changes  to  existing  commitments  should  be  negotiated  before  project  participants 
commit  to  the  requirement  or  requirement  change,  [acqj 

The  acquirer  negotiates  commitments  with  the  customer  and  supplier  before 
committing  to  the  requirement  changes,  [acq] 


SP  1.3  Manage  Requirements  Changes 

Manage  changes  to  the  requirements  as  they  evolve  during  the 
project. 


Refer  to  the  Configuration  Management  process  area  for  more 
information  about  maintaining  and  controlling  the  requirements  baseline 
and  on  making  the  requirements  and  change  data  available  to  the 
project. 
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During  the  project,  requirements  change  for  a  variety  of  reasons.  As 
needs  change  and  as  work  proceeds,  additional  requirements  are 
derived  and  changes  may  have  to  be  made  to  the  existing 
requirements.  It  is  essential  to  manage  these  additions  and  changes 
efficiently  and  effectively.  To  effectively  analyze  the  impact  of  the 
changes,  it  is  necessary  that  the  source  of  each  requirement  is  known 
and  the  rationale  for  any  change  is  documented.  The  project  manager 
may,  however,  want  to  track  appropriate  measures  of  requirements 
volatility  to  judge  whether  new  or  revised  controls  are  necessary. 

If  the  contractual  requirements  defined  in  supplier  agreement  are 
impacted  due  to  the  changes,  the  supplier  agreements  also  need  to  be 
aligned  with  the  changed  requirements,  [acqj 

Typical  Acquirer  Work  Products 

1 .  Requirements  change  requests  [acq] 

2.  Requirements  change  impact  reports  [acq] 

3.  Requirements  status 

4.  Requirements  database 

5.  Requirements  decision  database 

Typical  Supplier  Deliverables 

1 .  Requirements  change  requests  [acq] 

2.  Requirements  change  impact  reports  [acq] 

Subpractices 

1 .  Document  all  requirements  and  requirements  changes  that  are 
given  to  or  generated  by  the  project. 

2.  Maintain  the  requirements  change  history  with  the  rationale  for  the 
changes. 

Maintaining  the  change  history  helps  track  requirements  volatility,  [acq] 

3.  Evaluate  the  impact  of  requirement  changes  from  the  standpoint  of 
relevant  stakeholders. 

4.  Make  the  requirements  and  change  data  available  to  the  project. 


SP  1.4  Maintain  Bidirectional  Traceability  of  Requirements 

Maintain  bidirectional  traceability  among  the  requirements  and 
work  products. 


Requirements  Management 


315 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


The  intent  of  this  specific  practice  is  to  maintain  the  bidirectional 
traceability  of  requirements  for  each  level  of  product  decomposition. 
(See  the  definition  of  “bidirectional  traceability’’  in  the  glossary.)  When 
the  requirements  are  managed  well,  traceability  can  be  established 
from  the  source  requirement  to  its  lower  level  requirements  and  from 
the  lower  level  requirements  back  to  their  source.  Such  bidirectional 
traceability  helps  determine  that  all  source  requirements  have  been 
completely  addressed  and  that  all  lower  level  requirements  can  be 
traced  to  a  valid  source. 

Requirements  traceability  can  also  cover  the  relationships  to  other 
entities  such  as  intermediate  and  final  work  products,  changes  in  design 
documentation,  and  test  plans.  The  traceability  can  cover  horizontal 
relationships,  such  as  across  interfaces,  as  well  as  vertical 
relationships.  Traceability  is  particularly  needed  in  conducting  the 
impact  assessment  of  requirements  changes  on  the  project’s  activities 
and  work  products. 

The  supplier  maintains  comprehensive  bidirectional  traceability  to  the 
requirements  defined  in  the  supplier  agreement  by  the  acquirer,  and  the 
acquirer  verifies  that  traceability.  The  acquirer  traces  the  contractual 
requirements  to  the  customer  requirements,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Requirements  traceability  matrix 

2.  Requirements  tracking  system 

Typical  Supplier  Deliverables 

1 .  Comprehensive  requirements  traceability  matrix  managed  by  the 
supplier  as  required  by  the  supplier  agreement  [acq] 

Subpractices 

1 .  Maintain  requirements  traceability  to  ensure  that  the  source  of 
lower  level  (derived)  requirements  is  documented. 

The  traceability  from  contractual  requirements  to  derived  or  additional 
requirements  is  maintained  by  the  supplier,  [acqj 

2.  Maintain  requirements  traceability  from  a  requirement  to  its  derived 
requirements  and  allocation  to  functions,  interfaces,  objects, 
people,  processes,  and  work  products. 

3.  Generate  the  requirements  traceability  matrix. 

The  comprehensive  traceability  matrix,  tracing  from  contractual  requirements  to 
lower  level  requirements  is  maintained  by  the  supplier,  [acq] 
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SP  1.5  Identify  Inconsistencies  between  Project  Work  and  Requirements 

Identify  inconsistencies  between  the  project  plans  and  work 
products  and  the  requirements. 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  plans  and  work 
products  for  consistency  with  requirements  and  taking  corrective 
actions  when  necessary. 

This  specific  practice  finds  the  inconsistencies  between  the 
requirements  and  the  project  plans  and  work  products  and  initiates  the 
corrective  action  to  fix  them. 

Corrective  actions  taken  by  the  project  to  fix  inconsistencies  may  also 
result  in  changes  to  project  plans  and  supplier  agreements,  [acq] 

Typical  Acquirer  Work  Products 

1.  Documentation  of  inconsistencies  including  sources,  conditions, 
and  rationale  [acq] 

2.  Corrective  actions  [acq] 

Subpractices 

1 .  Review  the  project’s  plans,  activities,  and  work  products  for 
consistency  with  the  requirements  and  the  changes  made  to  them. 

2.  Identify  the  source  of  the  inconsistency  and  the  rationale. 

3.  Identify  changes  that  need  to  be  made  to  the  plans  and  work 
products  resulting  from  changes  to  the  requirements  baseline. 

4.  Initiate  corrective  actions. 
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RISK  MANAGEMENT 


A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Risk  Management  (RSKM)  is  to  identify  potential 
problems  before  they  occur  so  that  risk-handling  activities  can  be 
planned  and  invoked  as  needed  across  the  life  of  the  product  or  project 
to  mitigate  adverse  impacts  on  achieving  objectives. 


Introductory  Notes 


Risk  management  is  a  continuous,  forward-looking  process  that  is  an 
important  part  of  management.  Risk  management  should  address 
issues  that  could  endanger  achievement  of  critical  objectives.  A 
continuous  risk  management  approach  is  applied  to  effectively 
anticipate  and  mitigate  the  risks  that  may  have  a  critical  impact  on  the 
project. 

Effective  risk  management  includes  early  and  aggressive  risk 
identification  through  the  collaboration  and  involvement  of  relevant 
stakeholders,  as  described  in  the  stakeholder  involvement  plan 
addressed  in  the  Project  Planning  process  area.  Strong  leadership 
across  all  relevant  stakeholders  is  needed  to  establish  an  environment 
for  the  free  and  open  disclosure  and  discussion  of  risk. 

Risk  management  must  consider  both  internal  and  external  sources  for 
cost,  schedule,  and  performance  risk  as  well  as  other  risks.  Early  and 
aggressive  detection  of  risk  is  important  because  it  is  typically  easier, 
less  costly,  and  less  disruptive  to  make  changes  and  correct  work 
efforts  during  the  earlier,  rather  than  the  later,  phases  of  the  project. 

Risk  Management  has  two  contexts.  The  first  context  is  the 
identification  and  assessment  of  project  risks  during  the  project 
planning  process  and  managing  these  risks  throughout  the  project.  This 
includes  identifying  risks  associated  with  the  acquisition  process  and 
the  use  of  a  supplier  to  perform  project  work.  The  acquisition  strategy 
initially  identifies  the  risks  associated  with  an  acquisition.  The  approach 
to  the  acquisition  is  planned  based  upon  those  risks.  As  the  project 
progresses  to  the  selection  of  a  supplier,  the  risks  specific  to  the 
supplier’s  technical  and  management  approach  become  important  to 
the  success  of  the  acquisition.  These  risks  particularly  lie  in  the 
capability  of  the  supplier  to  meet  contractual  requirements,  including 
schedules  and  cost  targets,  [acqj 
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The  second  context  for  Risk  Management  is  following  the  selection  of  a 
supplier  and  award  of  the  supplier  agreement.  In  this  context,  the 
acquirer  continues  to  manage  project  risks,  including  those  risks  related 
to  the  supplier  meeting  contractual  requirements.  Typically  the  acquirer 
does  not  manage  risks  being  addressed  or  managed  by  the  supplier. 

[ACQ] 


Risk  management  can  be  divided  into  three  parts:  defining  a  risk 
management  strategy;  identifying  and  analyzing  risks;  and  handling 
identified  risks,  including  the  implementation  of  risk  mitigation  plans 
when  needed. 

Both  the  acquirer  and  the  supplier  must  understand  the  project  risks 
and  how  to  modify  the  risk  management  strategy  and  plans  as  a  project 
progresses  through  its  life  cycle.  Managing  a  project’s  risks  requires  a 
close  partnership  between  the  acquirer  and  the  supplier.  Both  the 
acquirer  and  the  supplier  need  to  share  appropriate  risk  management 
documentation,  understand  the  risks,  and  develop  and  execute  risk 
management  efforts,  [acqj 

Due  to  the  acquirer-supplier  relationship,  the  need  for  an  early  and 
aggressive  detection  of  risk  is  compounded  by  the  complexity  of 
projects  acquiring  products  and  services.  For  example,  the  acquirer’s 
capabilities,  the  supplier’s  experience  of  working  with  the  acquirer, 
financial  stability  of  the  supplier,  or  availability  of  well-defined  dispute 
resolution  processes  influence  the  risk  of  a  project,  [acq] 

As  represented  in  the  Project  Planning  and  Project  Monitoring  and 
Control  process  areas,  organizations  may  initially  focus  simply  on  risk 
identification  for  awareness,  and  react  to  the  realization  of  these  risks 
as  they  occur.  The  Risk  Management  process  area  describes  an 
evolution  of  these  specific  practices  to  systematically  plan,  anticipate, 
and  mitigate  risks  to  proactively  minimize  their  impact  on  the  project. 

Although  the  primary  emphasis  of  the  Risk  Management  process  area 
is  on  the  project,  the  concepts  can  also  be  applied  to  manage 
organizational  risks. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identification  of  project  risks  and  planning  for  involvement  of  relevant 
stakeholders. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  risks. 
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Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  to  evaluate 
alternatives  for  selection  and  mitigation  of  identified  risks. 

Refer  to  the  Solicitation  and  Supplier  Agreement  Development  process 
area  for  more  information  about  establishing  supplier  agreements,  [acqj 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Risk  Management 

SP  1 .1  Determine  Risk  Sources  and  Categories 
SP  1 .2  Define  Risk  Parameters 
SP  1 .3  Establish  a  Risk  Management  Strategy 
SG  2  Identify  and  Analyze  Risks 
SP2.1  Identify  Risks 

SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 
SG  3  Mitigate  Risks 

SP3.1  Develop  Risk  Mitigation  Plans 
SP  3.2  Implement  Risk  Mitigation  Plans 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Risk  Management 

Preparation  for  risk  management  is  conducted. 

Preparation  is  conducted  by  establishing  and  maintaining  a  strategy  for 
identifying,  analyzing,  and  mitigating  risks.  This  is  typically  documented 
in  a  risk  management  plan.  The  risk  management  strategy  addresses 
the  specific  actions  and  management  approach  used  to  apply  and 
control  the  risk  management  program.  This  includes  identifying  the 
sources  of  risk;  the  scheme  used  to  categorize  risks;  and  the 
parameters  used  to  evaluate,  bound,  and  control  risks  for  effective 
handling. 


SP  1.1  Determine  Risk  Sources  and  Categories 

Determine  risk  sources  and  categories. 


Identification  of  risk  sources  provides  a  basis  for  systematically 
examining  changing  situations  overtime  to  uncover  circumstances  that 
impact  the  ability  of  the  project  to  meet  its  objectives.  Risk  sources  are 
both  internal  and  external  to  the  project.  As  the  project  progresses, 
additional  sources  of  risk  may  be  identified.  Establishing  categories  for 
risks  provides  a  mechanism  for  collecting  and  organizing  risks  as  well 
as  ensuring  appropriate  scrutiny  and  management  attention  for  those 
risks  that  can  have  more  serious  consequences  on  meeting  project 
objectives. 
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Acquirers  identify  and  categorize  risk  sources  and  categories  for  the 
project  initially  and  refine  those  sources  and  categories  overtime  (e.g., 
schedule,  cost,  sourcing,  contract  management,  supplier  execution, 
technology  readiness,  human  safety,  reliability  related  risks  and  other 
issues  outside  the  control  of  the  acquirer).  The  supplier  is  also  a  source 
of  risk  (e.g.,  financial  stability  of  the  suppler  and  possibility  of  acquisition 
by  another  supplier),  [acqj 

Typical  Acquirer  Work  Products 

1 .  Risk  source  lists  (external  and  internal) 

2.  Risk  categories  list 
Subpractices 

1 .  Determine  risk  sources. 

Risk  sources  are  the  fundamental  drivers  that  cause  risks  within  a  project  or 
organization.  There  are  many  sources  of  risks,  both  internal  and  external,  to  a 
project.  Risk  sources  identify  common  areas  where  risks  may  originate.  Typical 
internal  and  external  risk  sources  include  the  following:  [acq] 

•  Uncertain  requirements 

•  Unprecedented  efforts— estimates  unavailable 

•  Infeasible  design 

•  Unavailable  technology 

•  Unrealistic  schedule  estimates  or  allocation 

•  Inadequate  staffing  and  skills 

•  Cost  or  funding  issues 

•  Uncertain  or  inadequate  subcontractor  capability 

•  Uncertain  or  inadequate  vendor  capability 

•  Disruptions  to  continuity  of  operations 

Many  of  these  sources  of  risk  are  often  accepted  without  adequate  planning.  Early 
identification  of  both  internal  and  external  sources  of  risk  can  lead  to  early 
identification  of  risks.  Risk  mitigation  plans  can  then  be  implemented  early  in  the 
project  to  preclude  occurrence  of  the  risks  or  reduce  the  consequences  of  their 
occurrence,  [acqj 

2.  Determine  risk  categories. 

Risk  categories  reflect  the  “bins”  for  collecting  and  organizing  risks.  A  reason  for 
identifying  risk  categories  is  to  help  in  the  future  consolidation  of  the  activities  in 
the  risk  mitigation  plans,  [acq] 
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The  following  factors  may  be  considered  when  determining  risk  categories:  [acqi 

•  The  phases  of  the  project’s  life-cycle  model  (e.g.,  requirements,  design, 
manufacturing,  test  and  evaluation,  delivery,  disposal) 

•  The  types  of  processes  used 

•  The  types  of  products  used 

•  Program  management  risks  (e.g.,  contract  risks,  budget/cost  risks,  schedule  risks, 
resources  risks,  performance  risks,  supportability  risks) 

•  Supplier  specific  risks  (e.g.,  financial  viability  of  the  supplier,  geographic  location 
of  supplier  resources). 

•  Safety,  security  and  reliability  of  the  product 


A  risk  taxonomy  can  be  used  to  provide  a  framework  for  determining  risk  sources 
and  categories,  [acqj 


SP  1.2  Define  Risk  Parameters 

Define  the  parameters  used  to  analyze  and  categorize  risks, 
and  the  parameters  used  to  control  the  risk  management  effort. 


Parameters  for  evaluating,  categorizing,  and  prioritizing  risks  include 
the  following: 

•  Risk  likelihood  (i.e.,  probability  of  risk  occurrence) 

•  Risk  consequence  (i.e.,  impact  and  severity  of  risk  occurrence) 

•  Thresholds  to  trigger  management  activities 

Risk  parameters  are  used  to  provide  common  and  consistent  criteria  for 
comparing  the  various  risks  to  be  managed.  Without  these  parameters, 
it  would  be  very  difficult  to  gauge  the  severity  of  the  unwanted  change 
caused  by  the  risk  and  to  prioritize  the  necessary  actions  required  for 
risk  mitigation  planning. 

Acquirers  should  record  the  parameters  used  to  analyze  and  categorize 
risk  so  that  they  are  available  throughout  the  project  period  for 
reference  when  circumstances  change  over  time.  In  this  way,  risks  can 
easily  be  re-categorized  and  analyzed  relative  to  the  original  information 
when  changes  occur  [acq] 

The  acquirer  may  use  tools  such  as  Failure  Mode  and  Effects  Analysis 
for  examining  risks  such  as  potential  failures  in  products  or  processes. 

It  may  be  used  to  evaluate  risk  management  priorities  for  mitigating 
known  threat-vulnerabilities,  [acqj 

Typical  Acquirer  Work  Products 

1.  Risk  evaluation,  categorization,  and  prioritization  criteria 
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2.  Risk  management  requirements  (e.g.,  control  and  approval  levels, 
reassessment  intervals) 

Subpractices 

1 .  Define  consistent  criteria  for  evaluating  and  quantifying  risk 
likelihood  and  severity  levels. 

Consistently  used  criteria  (e.g.,  the  bounds  on  the  likelihood  and  severity  levels) 
allow  the  impacts  of  different  risks  to  be  commonly  understood,  to  receive  the 
appropriate  level  of  scrutiny,  and  to  obtain  the  management  attention  warranted. 
In  managing  dissimilar  risks  (e.g.,  personnel  safety  versus  environmental 
pollution),  it  is  important  to  ensure  consistency  in  end  result  (e.g.,  a  high  risk  of 
environmental  pollution  is  as  important  as  a  high  risk  to  personnel  safety),  [acqi 

2.  Define  thresholds  for  each  risk  category. 

For  each  risk  category,  thresholds  can  be  established  to  determine  acceptability 
or  unacceptability  of  risks,  prioritization  of  risks,  or  triggers  for  management 
action,  [acqi 


Examples  of  thresholds  include  the  following:  [acqi 

•  Project-wide  thresholds  could  be  established  to  involve  senior  management  when 
product  costs  exceed  10  percent  of  the  target  cost  or  when  Cost  Performance 
Indexes  (CPIs)  fall  below  0.95. 

•  Schedule  thresholds  could  be  established  to  involve  senior  management  when 
Schedule  Performance  Indexes  (SPIs)  fall  below  0.95. 

•  Performance  thresholds  could  be  set  to  involve  senior  management  when 
specified  key  design  items  (e.g.,  processor  utilization)  exceed  125  percent  of  the 
intended  design. 


These  may  be  refined  later,  for  each  identified  risk,  to  establish  points  at  which 
more  aggressive  risk  monitoring  is  employed  or  to  signal  the  implementation  of 
risk  mitigation  plans,  [acqi 

3.  Define  bounds  on  the  extent  to  which  thresholds  are  applied 
against  or  within  a  category. 

There  are  few  limits  to  which  risks  can  be  assessed  in  either  a  quantitative  or 
qualitative  fashion.  Definition  of  bounds  (or  boundary  conditions)  can  be  used  to 
help  scope  the  extent  of  the  risk  management  effort  and  avoid  excessive  resource 
expenditures.  Bounds  may  include  exclusion  of  a  risk  source  from  a  category. 
These  bounds  can  also  exclude  any  condition  that  occurs  less  than  a  given 
frequency,  [acqi 


SP  1.3  Establish  a  Risk  Management  Strategy 

Establish  and  maintain  the  strategy  to  be  used  for  risk 
management. 
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A  comprehensive  risk  management  strategy  addresses  items  such  as 
the  following: 

•  The  scope  of  the  risk  management  effort 

•  Methods  and  tools  to  be  used  for  risk  identification,  risk  analysis, 
risk  mitigation,  risk  monitoring,  and  communication 

•  Project-specific  sources  of  risks 

•  How  these  risks  are  to  be  organized,  categorized,  compared,  and 
consolidated 

•  Parameters,  including  likelihood,  consequence,  and  thresholds,  for 
taking  action  on  identified  risks 

•  Risk  mitigation  techniques  to  be  used,  such  as  prototyping,  piloting, 
simulation,  alternative  designs,  or  evolutionary  development 

•  Definition  of  risk  measures  to  monitor  the  status  of  the  risks 

•  Time  intervals  for  risk  monitoring  or  reassessment 

The  risk  management  strategy  should  be  guided  by  a  common  vision  of 
success  that  describes  the  desired  future  project  outcomes  in  terms  of 
the  product  that  is  delivered,  its  cost,  and  its  fitness  for  the  task.  The 
risk  management  strategy  is  often  documented  in  an  organizational  or  a 
project  risk  management  plan.  The  risk  management  strategy  is 
reviewed  with  relevant  stakeholders  to  promote  commitment  and 
understanding. 

A  risk  management  strategy  must  be  developed  early  in  the  project,  so 
that  relevant  risks  are  identified  and  managed  aggressively.  The 
acquisition  strategy  evolves  based  on  risk  identification  and  analysis. 
The  early  identification  and  assessment  of  critical  risks  allows  the 
acquirer  to  formulate  risk  handling  approaches  and  to  streamline  the 
project  definition  and  the  solicitation  around  critical  product  and  process 
risks,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Project  risk  management  strategy 


SG  2  Identify  and  Analyze  Risks 

Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

The  degree  of  risk  impacts  the  resources  assigned  to  handle  an 
identified  risk  and  the  determination  of  when  appropriate  management 
attention  is  required. 
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Analyzing  risks  entails  identifying  risks  from  the  internal  and  external 
sources  identified  and  then  evaluating  each  identified  risk  to  determine 
its  likelihood  and  consequences.  Categorization  of  the  risk,  based  on  an 
evaluation  against  the  established  risk  categories  and  criteria 
developed  for  the  risk  management  strategy,  provides  the  information 
needed  for  risk  handling.  Related  risks  may  be  grouped  for  efficient 
handling  and  effective  use  of  risk  management  resources. 


SP  2.1  Identify  Risks 

Identify  and  document  the  risks. 


The  identification  of  potential  issues,  hazards,  threats,  and 
vulnerabilities  that  could  negatively  affect  work  efforts  or  plans  is  the 
basis  for  sound  and  successful  risk  management.  Risks  must  be 
identified  and  described  in  an  understandable  way  before  they  can  be 
analyzed  and  managed  properly.  Risks  are  documented  in  a  concise 
statement  that  includes  the  context,  conditions,  and  consequences  of 
risk  occurrence. 

Risk  identification  should  be  an  organized,  thorough  approach  to  seek 
out  probable  or  realistic  risks  in  achieving  objectives.  To  be  effective, 
risk  identification  should  not  be  an  attempt  to  address  every  possible 
event  regardless  of  how  highly  improbable  it  may  be.  Use  of  the 
categories  and  parameters  developed  in  the  risk  management  strategy, 
along  with  the  identified  sources  of  risk,  can  provide  the  discipline  and 
streamlining  appropriate  to  risk  identification.  The  identified  risks  form  a 
baseline  to  initiate  risk  management  activities.  The  list  of  risks  should 
be  reviewed  periodically  to  reexamine  possible  sources  of  risk  and 
changing  conditions  to  uncover  sources  and  risks  previously  overlooked 
or  nonexistent  when  the  risk  management  strategy  was  last  updated. 

Risk  identification  activities  focus  on  the  identification  of  risks,  not 
placement  of  blame.  The  results  of  risk  identification  activities  are  not 
used  by  management  to  evaluate  the  performance  of  individuals. 

There  are  many  methods  for  identifying  risks.  Typical  identification 
methods  include  the  following: 

•  Examine  each  element  of  the  project  work  breakdown  structure  to 
uncover  risks. 

•  Conduct  a  risk  assessment  using  a  risk  taxonomy. 

•  Interview  subject  matter  experts. 

•  Review  risk  management  efforts  from  similar  products. 

•  Examine  lessons-learned  documents  or  databases. 

•  Examine  design  specifications  and  agreement  requirements. 
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Some  risks  are  identified  by  examining  the  supplier’s  WBS,  product  and 
processes  using  the  categories  and  parameters  developed  in  the  risk 
management  strategy.  Risks  can  be  identified  in  many  areas,  e.g., 
requirements,  technology,  design,  testing,  vulnerability  to  threats,  life 
cycle  costs.  An  examination  of  the  project  in  these  areas  can  help  to 
develop  or  refine  the  acquisition  strategy  and  the  risk-sharing  structure 
between  the  acquirer  and  supplier,  [acq] 

The  acquirer  considers  the  risks  associated  with  a  supplier’s  capability 
(e.g.,  meeting  schedule  and  cost  requirements  for  the  project)  including 
the  potential  risks  to  the  acquirer’s  intellectual  capital  or  security 
vulnerabilities  introduced  by  using  a  supplier,  [acq] 

Typical  Acquirer  Work  Products 

1.  List  of  identified  risks,  including  the  context,  conditions,  and 
consequences  of  risk  occurrence 

Typical  Supplier  Deliverables 

1.  List  of  identified  risks,  including  the  context,  conditions,  and 
consequences  of  risk  occurrence  [acq] 

Subpractices 

1.  Identify  the  risks  associated  with  cost,  schedule,  and  performance. 

Cost,  schedule,  and  performance  risks  should  be  examined  during  all  phases  of 
the  product  life  cycle  in  the  acquirer’s  intended  environment  to  the  extent  that  they 
impact  project  objectives.  There  may  be  potential  risks  discovered  that  are  outside 
the  scope  of  the  project’s  objectives  but  vital  to  customer  interests.  For  example, 
the  risks  in  development  costs,  product  acquisition  costs,  cost  of  spare  (or 
replacement)  products,  and  product  disposition  (or  disposal)  costs  have  design 
implications.  The  customer  may  not  have  provided  requirements  for  the  cost  of 
supporting  the  fielded  product.  The  customer  should  be  informed  of  such  risks, 
but  actively  managing  those  risks  may  not  be  necessary.  The  mechanisms  for 
making  such  decisions  should  be  examined  at  project  and  organization  levels  and 
put  in  place  if  deemed  appropriate,  especially  for  risks  that  impact  the  ability  to 
verify  and  validate  the  product,  [acqi 

In  addition  to  the  cost  risks  identified  above,  other  cost  risks  may  include  those 
associated  with  funding  levels,  funding  estimates,  and  distributed  budgets,  [acqi 

Schedule  risks  may  include  risks  associated  with  planned  activities,  key  events, 
and  milestones,  [acq] 

Performance  risks  may  include  risks  associated  with  the  following:  [acq] 

•  Requirements 

•  Analysis  and  design 

•  Application  of  new  technology 
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•  Physical  size 

•  Shape 

•  Weight 

•  Manufacturing  and  fabrication 

•  Functional  performance  and  operation 

•  Verification 

•  Validation 

•  Performance  maintenance  attributes 

Performance  maintenance  attributes  are  those  characteristics  that  enable  an  in- 
use  product  or  service  to  provide  originally  required  performance,  such  as 
maintaining  safety  and  security  performance,  [acqi 

There  are  other  risks  that  do  not  fall  into  cost,  schedule,  or  performance 
categories,  [acqi 

Examples  of  these  other  risks  include  the  following:  [acqi 

•  Risks  associated  with  strikes 

•  Diminishing  sources  of  supply 

•  Technology  cycle  time 

•  Competition 


2.  Review  environmental  elements  that  may  impact  the  project. 

Risks  to  a  project  that  frequently  are  missed  include  those  supposedly  outside  the 
scope  of  the  project  (i.e.,  the  project  does  not  control  whether  they  occur  but  can 
mitigate  their  impact),  such  as  weather,  natural  or  manmade  disasters  that  affect 
continuity  of  operations,  political  changes,  and  telecommunications  failures,  [acqi 

3.  Review  all  elements  of  the  work  breakdown  structure  as  part  of 
identifying  risks  to  help  ensure  that  all  aspects  of  the  work  effort 
have  been  considered. 

4.  Review  all  elements  of  the  project  plan  as  part  of  identifying  risks  to 
help  ensure  that  all  aspects  of  the  project  have  been  considered. 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  identifying  project  risks. 

5.  Document  the  context,  conditions,  and  potential  consequences  of 
the  risk. 
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Risks  statements  are  typically  documented  in  a  standard  format  that  contains  the 
risk  context,  conditions,  and  consequences  of  occurrence.  The  risk  context 
provides  additional  information  such  that  the  intent  of  the  risk  can  be  easily 
understood.  In  documenting  the  context  of  the  risk,  consider  the  relative  time 
frame  of  the  risk,  the  circumstances  or  conditions  surrounding  the  risk  that  has 
brought  about  the  concern,  and  any  doubt  or  uncertainty,  [acqj 

6.  Identify  the  relevant  stakeholders  associated  with  each  risk. 


SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 

Evaluate  and  categorize  each  identified  risk  using  the  defined 
risk  categories  and  parameters,  and  determine  its  relative 
priority. 


The  evaluation  of  risks  is  needed  to  assign  relative  importance  to  each 
identified  risk,  and  is  used  in  determining  when  appropriate 
management  attention  is  required.  Often  it  is  useful  to  aggregate  risks 
based  on  their  interrelationships,  and  develop  options  at  an  aggregate 
level.  When  an  aggregate  risk  is  formed  by  a  roll  up  of  lower  level  risks, 
care  must  be  taken  to  ensure  that  important  lower  level  risks  are  not 
ignored. 

Collectively,  the  activities  of  risk  evaluation,  categorization,  and 
prioritization  are  sometimes  called  “risk  assessment”  or  “risk  analysis.” 

The  acquirer  should  conduct  a  risk  assessment  prior  to  solicitation  to 
evaluate  if  the  project  can  achieve  its  technical,  schedule,  and  budget 
constraints.  Technical,  schedule,  and  cost  risks  should  be  discussed 
with  potential  suppliers  before  the  solicitation  is  released.  In  this  way, 
critical  risks  inherent  in  the  project  can  be  identified  and  addressed  in 
the  solicitation,  [acq] 

Typical  Acquirer  Work  Products 

1 .  List  of  risks,  with  a  priority  assigned  to  each  risk 

Typical  Supplier  Deliverables 

1 .  List  of  risks,  with  a  priority  assigned  to  each  risk  [acq] 

Subpractices 

1.  Evaluate  the  identified  risks  using  the  defined  risk  parameters. 

Each  risk  is  evaluated  and  assigned  values  in  accordance  with  the  defined  risk 
parameters,  which  may  include  likelihood,  consequence  (severity,  or  impact),  and 
thresholds.  The  assigned  risk  parameter  values  can  be  integrated  to  produce 
additional  measures,  such  as  risk  exposure,  which  can  be  used  to  prioritize  risks 
for  handling,  [acq] 
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Often,  a  scale  with  three  to  five  values  is  used  to  evaluate  both  likelihood  and 
consequence.  Likelihood,  for  example,  can  be  categorized  as  remote,  unlikely, 
likely,  highly  likely,  or  a  near  certainty,  [acqj 

Examples  for  consequences  include  the  following:  [acqi 

•  Low 

•  Medium 
.  High 

•  Negligible 

•  Marginal 

•  Significant 

•  Critical 

•  Catastrophic 


Probability  values  are  frequently  used  to  quantify  likelihood.  Consequences  are 
generally  related  to  cost,  schedule,  environmental  impact,  or  human  measures 
(e.g.,  labor  hours  lost,  severity  of  injury),  [acqj 

This  evaluation  is  often  a  difficult  and  time-consuming  task.  Specific  expertise  or 
group  techniques  may  be  needed  to  assess  the  risks  and  gain  confidence  in  the 
prioritization,  in  addition,  priorities  may  require  reevaluation  as  time  progresses. 

[ACQ] 

2.  Categorize  and  group  risks  according  to  the  defined  risk 
categories. 

Risks  are  categorized  into  the  defined  risk  categories,  providing  a  means  to  look 
at  risks  according  to  their  source,  taxonomy,  or  project  component.  Related  or 
equivalent  risks  may  be  grouped  for  efficient  handling.  The  cause-and-effect 
relationships  between  related  risks  are  documented,  [acqi 

An  acquirer’s  risk  categories  may  include  sourcing,  contract  management, 
supplier  execution,  in  addition  to  project  management,  technology,  and 
requirements,  [acq] 

3.  Prioritize  risks  for  mitigation. 

A  relative  priority  is  determined  for  each  risk  based  on  the  assigned  risk 
parameters.  Clear  criteria  should  be  used  to  determine  the  risk  priority.  The  intent 
of  prioritization  is  to  determine  the  most  effective  areas  to  which  resources  for 
mitigation  of  risks  can  be  applied  with  the  greatest  positive  impact  to  the  project. 

[ACQ] 
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SG  3 


Mitigate  Risks 

Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse 
impacts  on  achieving  objectives. 

The  steps  in  handling  risks  include  developing  risk-handling  options, 
monitoring  risks,  and  performing  risk-handling  activities  when  defined 
thresholds  are  exceeded.  Risk  mitigation  plans  are  developed  and 
implemented  for  selected  risks  to  proactively  reduce  the  potential 
impact  of  risk  occurrence.  This  can  also  include  contingency  plans  to 
deal  with  the  impact  of  selected  risks  that  may  occur  despite  attempts  to 
mitigate  them.  The  risk  parameters  used  to  trigger  risk-handling 
activities  are  defined  by  the  risk  management  strategy. 


SP  3.1  Develop  Risk  Mitigation  Plans 

Develop  a  risk  mitigation  plan  for  the  most  important  risks  to 
the  project,  as  defined  by  the  risk  management  strategy. 


A  critical  component  of  a  risk  mitigation  plan  is  to  develop  alternative 
courses  of  action,  workarounds,  and  fallback  positions,  with  a 
recommended  course  of  action  for  each  critical  risk.  The  risk  mitigation 
plan  for  a  given  risk  includes  techniques  and  methods  used  to  avoid, 
reduce,  and  control  the  probability  of  occurrence  of  the  risk,  the  extent 
of  damage  incurred  should  the  risk  occur  (sometimes  called  a 
“contingency  plan”),  or  both.  Risks  are  monitored  and  when  they 
exceed  the  established  thresholds,  the  risk  mitigation  plans  are 
deployed  to  return  the  impacted  effort  to  an  acceptable  risk  level.  If  the 
risk  cannot  be  mitigated,  a  contingency  plan  can  be  invoked.  Both  risk 
mitigation  and  contingency  plans  are  often  generated  only  for  selected 
risks  where  the  consequences  of  the  risks  are  determined  to  be  high  or 
unacceptable;  other  risks  may  be  accepted  and  simply  monitored. 

Options  for  handling  risks  typically  include  alternatives  such  as  the 
following: 

•  Risk  avoidance:  Changing  or  lowering  requirements  while  still 
meeting  the  user’s  needs 

•  Risk  control:  Taking  active  steps  to  minimize  risks 

•  Risk  transfer:  Reallocating  requirements  to  lower  the  risks 

•  Risk  monitoring:  Watching  and  periodically  reevaluating  the  risk  for 
changes  to  the  assigned  risk  parameters 

•  Risk  acceptance:  Acknowledgment  of  risk  but  not  taking  any  action 

Often,  especially  for  high  risks,  more  than  one  approach  to  handling  a 
risk  should  be  generated. 
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For  example,  in  the  case  of  an  event  that  disrupts  continuity  of  operations,  approaches 
to  risk  management  can  include; 

•  Resource  reserves  to  respond  to  disruptive  events 

•  Lists  of  appropriate  back-up  equipment  to  be  available 

•  Back-up  personnel  for  key  personnel 

•  Plans  and  results  of/for  testing  emergency  response  systems 

•  Posted  procedures  for  emergencies 

•  Disseminated  lists  of  key  contacts  and  information  resources  for  emergencies 


In  many  cases,  risks  will  be  accepted  or  watched.  Risk  acceptance  is 
usually  done  when  the  risk  is  judged  too  low  for  formal  mitigation,  or 
when  there  appears  to  be  no  viable  way  to  reduce  the  risk.  If  a  risk  is 
accepted,  the  rationale  for  this  decision  should  be  documented.  Risks 
are  watched  when  there  is  an  objectively  defined,  verifiable,  and 
documented  threshold  of  performance,  time,  or  risk  exposure  (the 
combination  of  likelihood  and  consequence)  that  will  trigger  risk 
mitigation  planning  or  invoke  a  contingency  plan  if  it  is  needed. 

Thresholds  for  supplier  risks  that  affect  the  project  (e.g.,  schedule, 
quality  or  risk  exposure  due  to  supplier  risks)  are  specified  in  the 
supplier  agreement  along  with  escalation  actions  if  the  thresholds  are 
exceeded,  [acq] 


Adequate  consideration  should  be  given  early  to  technology 
demonstrations,  models,  simulations,  pilots,  and  prototypes  as  part  of 
risk  mitigation  planning. 

Typical  Acquirer  Work  Products 

1.  Documented  handling  options  for  each  identified  risk 

2.  Risk  mitigation  plans 

3.  Contingency  plans 

4.  Disaster  recovery  or  continuity  plans  [acq] 

5.  List  of  those  responsible  for  tracking  and  addressing  each  risk 

Typical  Supplier  Deliverables 

1.  Documented  handling  options  for  each  identified  risk  [acq] 

2.  Risk  mitigation  plans  [acq] 

3.  Contingency  plans  [acq] 

4.  Disaster  recovery  or  continuity  plans  [acq] 

5.  List  of  those  responsible  for  tracking  and  addressing  each  risk  [acq] 
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Subpractices 

1 .  Determine  the  levels  and  thresholds  that  define  when  a  risk 
becomes  unacceptable  and  triggers  the  execution  of  a  risk 
mitigation  plan  or  a  contingency  plan. 

Risk  level  (derived  using  a  risk  model)  is  a  measure  combining  the  uncertainty  of 
reaching  an  objective  with  the  consequences  of  failing  to  reach  the  objective,  [acq] 

Risk  levels  and  thresholds  that  bound  planned  or  acceptable  performance  must 
be  clearly  understood  and  defined  to  provide  a  means  with  which  risk  can  be 
understood.  Proper  categorization  of  risk  is  essential  for  ensuring  appropriate 
priority  based  on  severity  and  the  associated  management  response.  There  may 
be  multiple  thresholds  employed  to  initiate  varying  levels  of  management 
response.  Typically,  thresholds  for  the  execution  of  risk  mitigation  plans  are  set  to 
engage  before  the  execution  of  contingency  plans,  [acqj 

2.  Identify  the  person  or  group  responsible  for  addressing  each  risk. 

3.  Determine  the  cost-to-benefit  ratio  of  implementing  the  risk 
mitigation  plan  for  each  risk. 

Risk  mitigation  activities  should  be  examined  for  the  benefits  they  provide  versus 
the  resources  they  will  expend.  Just  like  any  other  design  activity,  alternative 
plans  may  need  to  be  developed  and  the  costs  and  benefits  of  each  alternative 
assessed.  The  most  appropriate  plan  is  then  selected  for  implementation.  At  times 
the  risk  may  be  significant  and  the  benefits  small,  but  the  risk  must  be  mitigated  to 
reduce  the  probability  of  incurring  unacceptable  consequences,  [acq] 

4.  Develop  an  overall  risk  mitigation  plan  for  the  project  to  orchestrate 
the  implementation  of  the  individual  risk  mitigation  and  contingency 
plans. 

The  complete  set  of  risk  mitigation  plans  may  not  be  affordable.  A  tradeoff 
analysis  should  be  performed  to  prioritize  the  risk  mitigation  plans  for 
implementation,  [acqj 

5.  Develop  contingency  plans  for  selected  critical  risks  in  the  event 
their  impacts  are  realized. 

Risk  mitigation  plans  are  developed  and  implemented  as  needed  to  proactively 
reduce  risks  before  they  become  problems.  Despite  best  efforts,  some  risks  may 
be  unavoidable  and  will  become  problems  that  impact  the  project.  Contingency 
plans  can  be  developed  for  critical  risks  to  describe  the  actions  a  project  may  take 
to  deal  with  the  occurrence  of  this  impact.  The  intent  is  to  define  a  proactive  plan 
for  handling  the  risk,  either  to  reduce  the  risk  (mitigation)  or  respond  to  the  risk 
(contingency),  but  in  either  event  to  manage  the  risk,  [acqj 

Some  risk  management  literature  may  consider  contingency  plans  a  synonym  or 
subset  of  risk  mitigation  plans.  These  plans  also  may  be  addressed  together  as 
risk-handling  or  risk  action  plans,  [acqj 
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SP  3.2  Implement  Risk  Mitigation  Plans 

Monitor  the  status  of  each  risk  periodically  and  implement  the 
risk  mitigation  plan  as  appropriate. 


To  effectively  control  and  manage  risks  during  the  work  effort,  follow  a 
proactive  program  to  regularly  monitor  risks  and  the  status  and  results 
of  risk-handling  actions.  The  risk  management  strategy  defines  the 
intervals  at  which  the  risk  status  should  be  revisited.  This  activity  may 
result  in  the  discovery  of  new  risks  or  new  risk-handling  options  that  can 
require  replanning  and  reassessment.  In  either  event,  the  acceptability 
thresholds  associated  with  the  risk  should  be  compared  against  the 
status  to  determine  the  need  for  implementing  a  risk  mitigation  plan. 

The  acquirer  shares  selected  risks  with  the  supplier.  Risks  associated 
specifically  with  the  acquisition  process  are  tracked  and  resolved  or 
controlled  until  mitigated.  This  monitoring  includes  risks  that  may  be 
escalated  by  the  supplier,  [acq] 

Typical  Acquirer  Work  Products 

1 .  Updated  lists  of  risk  status 

2.  Updated  assessments  of  risk  likelihood,  consequence,  and 
thresholds 

3.  Updated  lists  of  risk-handling  options 

4.  Updated  list  of  actions  taken  to  handle  risks 

5.  Risk  mitigation  plans 

Typical  Supplier  Deliverables 

1 .  Updated  lists  of  risk  status  [acq] 

2.  Updated  assessments  of  risk  likelihood,  consequence,  and 
thresholds  [acq] 

3.  Updated  lists  of  risk-handling  options  [acq] 

4.  Updated  list  of  actions  taken  to  handle  risks  [acq] 

5.  Risk  mitigation  plans  [acq] 

Subpractices 

1.  Monitor  risk  status. 

After  a  risk  mitigation  plan  is  initiated,  the  risk  is  still  monitored.  Thresholds  are 
assessed  to  check  for  the  potential  execution  of  a  contingency  plan,  [acqj 

A  periodic  mechanism  for  monitoring  should  be  employed,  [acq] 

2.  Provide  a  method  for  tracking  open  risk-handling  action  items  to 
closure. 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items. 

3.  Invoke  selected  risk-handling  options  when  monitored  risks  exceed 
the  defined  thresholds. 

Quite  often,  risk  handling  is  only  performed  for  those  risks  judged  to  be  “high”  and 
“medium."  The  risk-handling  strategy  for  a  given  risk  may  include  techniques  and 
methods  to  avoid,  reduce,  and  control  the  likelihood  of  the  risk  or  the  extent  of 
damage  incurred  should  the  risk  (anticipated  event  or  situation)  occur  or  both.  In 
this  context,  risk  handling  includes  both  risk  mitigation  plans  and  contingency 
plans,  [acq] 

Risk-handling  techniques  are  developed  to  avoid,  reduce,  and  control  adverse 
impact  to  project  objectives  and  to  bring  about  acceptable  outcomes  in  light  of 
probable  impacts.  Actions  generated  to  handle  a  risk  require  proper  resource 
loading  and  scheduling  within  plans  and  baseline  schedules.  This  replanning 
effort  needs  to  closely  consider  the  effects  on  adjacent  or  dependent  work 
initiatives  or  activities,  [acqj 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  revising  the  project  plan. 

4.  Establish  a  schedule  or  period  of  performance  for  each  risk¬ 
handling  activity  that  includes  the  start  date  and  anticipated 
completion  date. 

5.  Provide  continued  commitment  of  resources  for  each  plan  to  allow 
successful  execution  of  the  risk-handling  activities. 

6.  Collect  performance  measures  on  the  risk-handling  activities. 
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SOLICITATION  AND  SUPPLIER  AGREEMENT  DEVELOPMENT 

An  Acquisition  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Solicitation  and  Supplier  Agreement  Development 
(SSAD)  is  to  prepare  a  solicitation  package  and  to  select  one  or  more 
suppliers  for  delivering  the  product  or  service. 


Introductory  Notes 


The  Solicitation  and  Supplier  agreement  development  process  area 
includes  developing  the  acquisition  strategy.  The  acquisition  strategy  is 
a  guide  to  direct  and  control  the  project  and  a  framework  to  integrate 
the  activities  essential  to  acquiring  an  operational  product. 

The  Solicitation  and  Supplier  Agreement  Development  process  area 
provides  a  set  of  practices  that  enable  the  acquirer  to  initialize  and 
formalize  a  relationship  with  the  supplier  for  the  successful  execution  of 
the  project.  A  formal  agreement  is  any  legal  agreement  between  the 
organization  (representing  the  project)  and  the  supplier.  This  agreement 
may  be  a  contract,  a  license,  or  a  memorandum  of  agreement.  The 
acquired  product  is  delivered  to  the  project  from  the  supplier  according 
to  this  formal  agreement  (also  known  as  the  “supplier  agreement”). 

The  supplier  agreement  created  using  these  practices  enables  the 
acquirer  to  execute  its  monitoring  and  control  of  supplier  activities  using 
other  process  areas,  such  as  Project  Monitoring  and  Control  and 
Acquisition  Management. 

The  practices  of  this  process  area  apply  equally  to  initial  supplier 
agreements  and  to  subsequent  change  orders,  task  orders,  or 
amendments  related  to  those  agreements. 

The  acquirer  is  responsible  for  establishing  and  maintaining  the  ground 
rules  for  supplier  communication,  documenting  decisions,  and  conflict 
resolution  through  the  life  of  the  agreement.  The  acquirer  facilitates 
these  activities  with  relevant  project  stakeholders.  Specific  roles  and 
responsibilities  of  relevant  project  stakeholders  for  interaction  with  or 
direction  of  the  suppliers  are  defined,  coordinated,  and  adhered  to. 
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The  specific  goals  and  specific  practices  of  this  process  area  build  on 
each  other  in  the  following  way.  The  Prepare  for  Solicitation  and 
Supplier  Agreement  Development  specific  goal  and  associated 
practices  identify  potential  suppliers  and  develop  the  evaluation  criteria 
and  the  solicitation  package.  The  solicitation  package  is  developed 
using  work  products  from  other  process  areas,  e.g.,  requirements  from 
Acquisition  Requirements  Development  and  design  constraints  from 
Acquisition  Technical  Solution.  The  Select  Suppliers  specific  goal  and 
associated  specific  practices  use  the  work  products  from  the 
preparation  for  solicitation  to  solicit  responses  from  potential  suppliers, 
evaluate  these  responses,  negotiate  and  select  a  supplier  who  can  best 
deliver  to  the  solicitation  package.  Subsequently,  the  “Establish 
Supplier  Agreement”  specific  goal  and  associated  practices  are  used  to 
document  the  approved  supplier  agreement.  In  turn,  the  data  provided 
by  the  supplier  and  documented  in  the  supplier  agreement  (e.g.,  cost, 
schedule,  risks)  is  used  by  Project  Planning  practices  to  update  the 
project  plan. 

Although  this  process  area  describes  acquisition  practices  for  a  project, 
an  acquirer  would  use  the  same  practices  in  establishing  a  supplier 
agreement  for  multiple  projects  .The  requirements  included  in  the 
solicitation  package  and  the  supplier  agreement  would  reflect  the 
broader  scope,  and  the  evaluation  and  selection  process  would  require 
an  appropriate  level  of  review  before  a  selection  is  made. 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  information  on  planning 
for  solicitation,  including  developing  and  documenting  the  project  plan 
for  the  acquisition,  estimating  the  supplier’s  work,  and  for  information 
about  revising  the  project  plan. 

Refer  to  the  Acquisition  Requirements  Development  process  area  for 
more  information  about  defining  customer  and  contractual 
requirements. 

Refer  to  Acquisition  Verification  and  Acquisition  Validation  process 
areas  for  more  information  about  evaluating  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements,  including  the  traceability  of 
requirements  for  products  acquired  from  suppliers  and  for  managing 
changes  to  requirements. 

Refer  to  the  Acquisition  Technical  Solution  process  area  for  more 
information  about  determining  the  design  constraints,  including 
standards  that  are  included  in  the  solicitation  package. 
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Refer  to  the  Acquisition  Management  process  area  for  more  information 
about  managing  selected  suppliers’  activities  based  upon  the  supplier 
agreement. 

Refer  to  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation  approaches  that  can  be  used  to 
select  suppliers. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Solicitation  and  Supplier  Agreement  Development 
SP  1 .1  Develop  Acquisition  Strategy 

SP  1 .2  Identify  Potential  Suppliers 

SP  1 .3  Develop  Solicitation  Package 

SP  1 .4  Review  the  Solicitation  Package 
SP  1 .5  Distribute  the  Solicitation  Package 
SG  2  Select  Suppliers 

SP2.1  Evaluate  Proposed  Solutions 

SP  2.2  Develop  Negotiation  Plans 

SP2.3  Finalize  Supplier  Selection 

SG  3  Establish  Supplier  Agreement 

SP  3.1  Establish  Mutual  Understanding  of  the  Agreement 
SP  3.2  Document  Supplier  Agreement 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Solicitation  and  Supplier  Agreement  Development 

Develop  the  acquisition  strategy,  qualify  potential  suppliers  and  develop  a 
solicitation  package  that  includes  the  requirements  and  proposal 
evaluation  criteria. 


SP  1.1  Develop  the  Acquisition  Strategy 

Develop  and  maintain  the  overall  acquisition  strategy  content. 


The  acquisition  strategy  is  the  business  and  technical  management 
framework  for  planning,  directing,  contracting  for,  and  managing  a 
project  or  program.  The  acquisition  strategy  relates  to  the  objectives  for 
the  acquisition,  the  constraints,  availability  of  resources  and 
technologies,  consideration  of  acquisition  methods,  potential  supplier 
agreement  types,  terms  and  conditions,  accommodation  of  business 
considerations,  considerations  of  risk,  and  support  for  the  acquired 
product  over  its  life  cycle. 
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The  acquisition  strategy  results  from  a  thorough  understanding  of  both 
the  specific  acquisition  project  or  program  and  the  general  acquisition 
environment.  The  acquirer  accounts  for  the  potential  value  or  benefit  of 
the  acquisition  in  the  light  of  the  potential  risks,  considers  constraints, 
and  takes  into  account  experiences  with  different  types  of  suppliers, 
agreements  and  terms.  A  well-developed  strategy  minimizes  the  time 
and  cost  required  to  satisfy  approved  capability  needs,  and  maximizes 
affordability  throughout  the  project  life  cycle. 

The  acquisition  strategy  for  a  project  typically  tailors  a  program  or 
organizational  level  acquisition  strategy. 

Refer  to  the  Organizational  Process  Definition  process  area  for 
information  about  tailoring  criteria  and  guidelines. 

The  acquisition  strategy  is  the  basis  for  formulating  solicitation 
packages,  supplier  agreements,  and  project  plans.  The  strategy  evolves 
over  time  and  should  continuously  reflect  the  current  status  and  desired 
end  point  of  the  project. 

Typical  Acquirer  Work  Products 

1.  Acquisition  strategy 

Subpractices 

1 .  Identify  the  capabilities  and  objectives  the  acquisition  is  intended  to 
satisfy  or  provide 

The  capabilities  describe  what  the  organization  intends  to  acquire.  Typically  the 
capability  included  in  the  acquisition  strategy  summary  highlights  product 
characteristics  driven  by  interoperability  and/or  and  families  of  products.  It  also 
identifies  any  dependency  on  planned  or  existing  capabilities  of  other  projects  or 
products. 

Refer  to  Acquisition  Requirements  Development  for  information 
about  determining  capabilities  and  customer  requirements. 

At  a  minimum,  the  acquirer  identifies  the  cost,  schedule,  and  key  performance 
objectives  for  the  acquisition.  Each  objective  consists  of  an  objective  value 
representing  customer  expectations  and  a  threshold  value  representing 
acceptable  limits  that,  in  the  customer’s  judgment,  still  provide  the  needed 
capability.  While  the  number  and  specificity  of  performance  parameters  may 
change  over  the  duration  of  an  acquisition,  the  acquirer  typically  focuses  on  the 
minimum  number  of  parameters  that,  if  thresholds  are  not  met,  will  require  a  re- 
evaluation  of  the  project. 
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The  acquisition  strategy  establishes  the  milestone  decision  points  and  acquisition 
phases  planned  for  the  project.  It  prescribes  the  accomplishments  for  each  phase, 
and  identifies  the  critical  events  affecting  project  management.  Schedule 
parameters  include,  at  a  minimum,  the  projected  dates  for  the  project  initiation, 
other  major  decision  points,  and  initial  operational  capability. 


:  Examples  of  cost  parameters  include  the  following: 

:  •  Research,  development,  test,  and  evaluation  costs 
:  •  Procurement  costs 

j  •  Acquisition  related  operations,  support,  and  disposal  costs 

j  •  Total  product  quantity  (to  include  both  fully  configured  development  and 
production  units) 

2.  Identify  the  acquisition  approach 

The  acquirer  defines  the  approach  the  project  will  use  to  achieve  full  capability: 
either  evolutionary  or  single  step;  it  should  include  a  brief  rationale  to  justify  the 
choice.  When  a  project  uses  an  evolutionary  acquisition  approach,  the  acquisition 
strategy  describes  the  initial  capability,  and  how  it  will  be  funded,  developed, 
tested,  produced,  and  supported.  The  acquisition  strategy  previews  similar 
planning  for  subsequent  increments,  and  identifies  the  approach  to  integrate 
and/or  retrofit  earlier  increments  with  later  increments. 


Examples  of  additional  considerations  for  the  acquisition  approach  include  the 
j  following: 

:  •  Actions  a  project  team  can  take  on  their  own,  if  the  acquiring  organization  or  unit 
has  a  procurement,  contracting,  or  purchasing  department 

i  •  Who  will  prepare  independent  estimates  and  if  they  are  need  as  evaluation  criteria 

j  •  Managing  multiple  suppliers 

.  •  Anticipated  lead  times  from  potential  suppliers  to  acquire  items 

3.  Document  business  considerations 


:  Examples  of  business  considerations  for  an  acquisition  strategy  include  the 
i  following: 

j  •  Competition  planned  for  all  phases  of  acquisition,  or  explains  why  competition  is 
j  not  practicable  or  not  in  the  best  interests  of  the  acquirer.  This  includes 
j  considerations  for  establishing  or  maintaining  access  to  competitive  suppliers  for 
j  critical  areas  at  the  product  or  product  components. 

:  •  Product  and  technology  areas  critical  to  satisfy  or  provide  the  desired  capabilities. 

i  •  Availability  and  suitability  of  commercial  items  and  the  extent  to  which  the 

interfaces  for  these  items  have  broad  market  acceptance,  standards-organization 
support,  and  stability.  This  includes  considerations  for  both  international  and 
i  domestic  sources  that  can  meet  the  required  need,  as  the  primary  sources  of 
supply  consistent  with  organizational  policies  and  regulations. 


4.  Identify  major  risks  and  risk  sharing  with  the  supplier 
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All  acquisition  risks,  whether  primarily  managed  by  the  acquirer  or  by  the  supplier, 
must  be  assessed  and  managed  by  the  acquirer.  The  acquisition  strategy 
describes  how  risk  is  to  be  handled  and  identifies  major  risks  and  which  risks  are 
to  be  shared  with  the  supplier  and  which  are  to  be  retained  by  acquirer. 

Refer  to  Risk  Management  for  information  about  determining 
capabilities  and  customer  requirements. 

5.  Identify  the  supplier  agreement  type 

The  acquirer  identifies  standardized  procurement  documents  (e.g.,  standard 
supplier  agreements),  if  any.  The  acquirer  also  determines  the  type  of  supplier 
agreement  planned  (e.g.,  firm  fixed-price;  fixed-price  incentive,  firm  target;  cost 
plus  incentive  fee;  or  cost  plus  award  fee)  and  the  reasons  it  is  suitable,  including 
considerations  of  risk  assessment  and  reasonable  risk-sharing  by  the  acquirer 
and  the  supplier. 

The  acquisition  strategy  explains  the  planned  incentive  structure  for  the 
acquisition,  and  how  it  incentivizes  the  supplier  to  provide  the  product  or  services 
at  or  below  the  established  cost  objectives  and  satisfy  the  schedule  and  key 
performance  objectives.  If  more  than  one  incentive  is  planned  for  a  supplier 
agreement,  the  acquisition  strategy  explains  how  the  incentives  complement  each 
other  and  do  not  interfere  with  one  another.  The  acquisition  strategy  identifies  any 
unusual  terms  and  conditions  of  the  planned  supplier  agreement  and  all  existing 
or  contemplated  deviations  to  an  organization’s  terms  and  conditions,  if  any. 

6.  Identify  the  product  support  strategy 

The  acquirer  develops  a  product  support  strategy  for  life  cycle  sustainment  and 
continuous  improvement  of  product  affordability,  reliability,  and  supportability, 
while  sustaining  readiness.  The  support  strategy  addresses  how  the  acquirer  will 
maintain  oversight  of  the  fielded  product. 

The  acquirer’s  sustainment  organization  or  supplier  typically  participates  in 
product  support  strategy  development. 

7.  Review  and  obtain  agreement  with  senior  management  on  the 
acquisition  strategy 

The  development  of  the  acquisition  strategy  for  a  project  typically  requires  senior 
management  sponsorship.  The  appropriate  senior  management  needs  to  approve 
the  acquisition  strategy  before  initiating  a  project. 

SP  1.2  Identify  Potential  Suppliers 

Identify  and  qualify  potential  suppliers. 
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Consistent  with  the  acquisition  strategy  and  along  with  the  scope  and 
requirements  for  the  project  or  program,  the  acquirer  identifies  potential 
suppliers  to  receive  the  solicitation.  The  acquirer  can  identify  suppliers 
from  a  variety  of  sources  (e.g.,  employees,  international  seminars, 
market  analysis  reports). 

Acquirers  need  to  limit  the  number  of  suppliers  they  solicit  proposals 
from  in  order  to  reduce  their  cost  and  efforts  for  the  solicitation,  while  at 
the  same  time  making  sure  they  have  included  suppliers  who  are 
capable  of  meeting  the  requirements  and  that  enough  suppliers  are 
included  to  provide  a  competitive  environment.  This  competition 
enhances  the  leverage  of  the  acquirer  in  achieving  its  objectives  (e.g., 
providing  different  approaches  to  meeting  the  requirements). 

Depending  upon  the  applicable  regulations  or  characteristics  of  the 
project,  the  acquirer  may  determine  to  sole  source  the  project  rather 
than  place  it  for  competitive  bid. 

Typical  Acquirer  Work  Products 

1 .  List  of  potential  suppliers  prepared  to  respond  to  the  solicitation 
Subpractices 

1 .  Develop  a  list  of  potential  suppliers. 

In  developing  the  list  of  potential  suppliers,  the  acquirer  considers  which  suppliers 
have  had  experience  with  similar  systems  or  projects,  what  kind  of  performance 
the  acquirer  has  experienced  with  suppliers  on  previous  projects,  what  suppliers 
are  likely  to  provide  the  specific  capabilities  needed  for  the  project,  and  what  is 
the  availability  of  critical  resources  to  staff  and  support  the  project.  In  addition  to 
assessing  the  supplier’s  capabilities,  a  risk  assessment  is  prepared  on  the 
supplier’s  financial  capabilities  (e.g.,  creditworthiness,  financial  stability  and 
access  to  capital  and  the  impact  to  the  supplier  of  a  successful  bid). 

2.  Communicate  with  potential  suppliers  concerning  the  forthcoming 
solicitation. 

The  acquirer  contacts  the  suppliers  to  outline  the  plans  for  the  solicitation, 
including  the  projected  schedule  for  releasing  the  solicitation  package  and  the 
expected  dates  for  responses  from  suppliers.  If  the  supplier  indicates  their  interest 
in  responding  to  the  solicitation,  the  appropriate  confidentiality  agreements  are  put 
in  place. 

Typical  information  included  in  communication  to  candidate  suppliers: 

•  Anticipated  scope  of  the  solicitation 

•  Schedule  for  release  of  the  solicitation  package 

•  Overall  project  schedule 

•  Approach/procedures  that  will  be  used  throughout  the  solicitation  process 
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•  High  level  criteria  for  evaluating  proposal  responses 

•  Required  supplier  qualifications,  e.g.,  appraisal  at  a  specific  CMMI  level 

•  Schedule  for  return  of  proposal 

•  Date  for  supplier  to  indicate  if  it  will  or  will  not  participate  in  the  solicitation 

3.  Verify  the  participants  who  will  evaluate  supplier  proposals. 

4.  Verify  the  participants  in  supplier  negotiations. 


SP  1.3  Develop  Solicitation  Package 

Establish  and  maintain  a  solicitation  package  that  includes  the 
requirements  and  proposal  evaluation  criteria. 


Solicitation  packages  are  used  to  seek  proposals  from  potential 
suppliers.  The  acquirer  structures  the  solicitation  package  to  facilitate 
an  accurate  and  complete  response  from  each  potential  supplier  and  to 
allow  for  an  effective  comparison  and  evaluation  of  proposals. 

The  solicitation  package  includes  a  description  of  the  desired  form  of 
the  response,  the  relevant  statement  of  work  for  the  supplier,  and  any 
required  contractual  provisions  (e.g.,  a  copy  of  the  standard  supplier 
agreement,  non-disclosure  provisions).  With  government  agreements, 
some  or  all  of  the  content  and  structure  of  the  solicitation  package  can 
be  defined  by  regulation. 

The  solicitation  package  typically  contains  the  following: 

•  The  statement  of  work  for  the  supplier,  including  supplier  measures 
and  service  levels 

•  Guidance  on  how  potential  suppliers  are  to  respond  to  the 
solicitation  package 

•  Criteria  that  will  be  used  to  evaluate  the  proposals 

•  Documentation  requirements  to  submit  with  the  response  (e.g., 
project  plans) 

•  Schedule  for  completing  the  solicitation  process 

•  Procedures  for  addressing  questions  and  contacts 

The  solicitation  package  is  rigorous  enough  to  ensure  consistent, 
comparable  responses,  but  flexible  enough  to  allow  consideration  of 
supplier  suggestions  for  better  ways  to  satisfy  the  requirements.  Inviting 
the  suppliers  to  submit  a  proposal  that  is  wholly  responsive  to  the 
request  for  proposal  and  to  provide  a  proposed  alternative  solution  in  a 
separate  proposal  can  do  this. 
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The  complexity  and  level  of  detail  of  the  solicitation  package  should  be 
consistent  with  the  value  of,  and  risk  associated  with  the  planned 
acquisition.  In  some  cases,  the  solicitation  may  not  include  detailed 
requirements  (e.g.,  it  may  be  a  solicitation  for  development  of  detailed 
requirements  or  it  may  include  a  statement  of  objectives  to  provide  the 
supplier  greater  flexibility  in  addressing  the  scope  of  the  project). 
Proposal  and  supplier  evaluation  criteria  are  identified  and  documented. 

Typical  Acquirer  Work  Products 

1.  Solicitation  package 

2.  Supplier  and  proposal  evaluation  criteria 
Subpractices 

1 .  Develop  the  statement  of  work  for  the  supplier 

The  statement  of  work  for  the  supplier  defines,  for  those  items  being  acquired,  just 
the  portion  of  the  project  scope  that  is  included  within  the  related  supplier 
agreement.  The  statement  of  work  for  a  supplier  is  developed  from  the  project 
scope,  the  work  breakdown  structure  and  task  dictionary. 

The  statement  of  work  for  the  supplier  is  written  to  be  clear,  complete,  and 
concise.  It  describes  the  acquired  product  or  service  in  sufficient  detail  to  allow 
prospective  suppliers  to  determine  if  they  are  capable  of  providing  the  product  or 
service. 
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Example  content  of  the  statement  of  work  for  the  supplier  includes  the  following: 

:  •  Project  or  program  objectives 

:  •  Requirements  (incl.  period  of  performance,  work  location,  legal,  statutory  and 
j  regulatory  requirements) 

j  •  Design  constraints 

:  •  Deliverables  and  rights  (e.g.,  work  breakdown  structure  of  the  supplier’s  work, 
detailed  design,  test  results) 

i  •  Expectations  for  supplier  transition  of  product  to  operations 

j  •  Measurements,  service  levels,  and  reports  that  provide  the  acquirer  visibility  into 
j  the  supplier’s  process  and  results 

j  •  Collateral  services  required  (e.g.  study  reports,  development  of  training  materials, 
j  delivering  training  to  end  users) 

:  •  Acquirer  specified  standard  processes  for  the  project  (e.g.,  configuration 
:  management,  escalation,  corrective  action  for  non-conformances,  conflict 

:  resolution,  and  change  management) 

:  •  The  type  of  reviews  that  will  be  conducted  with  the  supplier  and  other 
:  communication  processes  and  procedures 

j  •  Product  acceptance  criteria 

•  Post-project  support 

The  statement  of  work  for  the  supplier  can  be  revised  and  refined  as  required  as  it 
moves  through  the  solicitation  and  supplier  agreement  development  process  until 
incorporated  into  a  signed  supplier  agreement.  For  example,  a  prospective 
supplier  can  suggest  a  more  efficient  approach  or  a  less  costly  product  than  that 
originally  specified. 

2.  Specify  the  measures,  acceptance  criteria,  and  the  associated 
service  levels  for  the  supplier. 

Service  levels  are  designed  to  support  the  acquisition  strategy.  Typically  the 
service  levels  are  a  limited  set  with  a  precise  definition,  including  the  assessment 
and  calculation  of  incentives  and  penalties. 
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Examples  of  considerations  for  service  levels  include  the  following: 

•  Specific  methodology  to  be  followed  in  measuring  supplier  performance,  including 
goals,  objectives,  credits,  earnbacks,  and  measurement  calculations. 

•  On-going  level  of  performance  of  the  service  acquired,  the  minimum  allowed 
performance  level,  and  the  amount  of  credit  allocated  to  each  performance 
measurement 

•  One-time  deliverables  with  monthly  credits  to  the  acquirer  for  non-performance  by 
the  supplier 


A  service  level  for  a  project,  for  example,  may  refer  to  an  output  from  the  supplier, 
such  as  providing  a  specific  deliverable  at  an  agreed  upon  time,  and  to  the  quality 
of  that  output.  Service  levels  also  (directly  or  indirectly)  refer  to  progress 
measures,  e.g.,  %  of  completion  of  that  deliverable  according  to  schedule,  to 
initiate  corrective  action  based  on  their  associated  performance  target  or 
thresholds,  for  instance,  if  the  supplier  doesn’t  appear  to  be  on  schedule  to  meet 
the  service  level  agreement,  in  this  example  on  time  completion  of  a  deliverable. 

Refer  to  the  Project  Monitoring  and  Control  practices  for  more 
information  on  the  use  of  supplier  measurement  data  to  monitor  a 
project. 

4.  Develop  supplier  evaluation  and  proposal  evaluation  criteria. 

Evaluation  criteria  are  developed  and  used  to  rate  or  score  proposals.  Evaluation 
criteria  are  included  as  apart  of  the  solicitation  package.  Evaluation  criteria  can  be 
limited  to  purchase  price  if  the  procurement  item  is  readily  available  from  a 
number  of  acceptable  suppliers.  Purchase  price  in  this  context  includes  both  the 
cost  of  the  item  and  ancillary  expenses  such  as  delivery.  Other  selection  criteria 
can  be  identified  and  documented  to  support  an  assessment  for  a  more  complex 
product  or  service  (e.g.,  the  individuals  identified  in  the  Project  Planning  resource 
plan,  develop,  and  document  the  criteria  for  evaluating  potential  suppliers  and  for 
evaluating  their  proposals). 
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Examples  of  areas  to  evaluate  the  potential  suppliers’  ability  and  proposals 
:  include  the  following: 

|  •  compliance  to  stated  requirements  contained  in  the  solicitation  package 

:  •  experience  with  similar  products  or  services  (e.g.,  familiarity  with  the  acquirer’s 
:  processes,  technical  environment  and  the  core  business) 

i  •  total  ownership  and  life-cycle  cost 

I  •  technical  capability  (e.g.,  expected  functional  and  performance  compliance  to  the 
requirements  and  criteria,  given  the  architecture  and  technical  solution  proposed) 

|  •  management  and  delivery  processes  and  procedures 

:  •  proposed  technical  methodologies,  techniques,  solutions,  and  services 

i  •  financial  capability 

|  •  production  capacity  and  interest  (e.g.,  staff  available  to  perform  the  effort, 

:  available  facilities  and  resources) 

:  •  business  size  and  type 

•  intellectual  property  and  proprietary  rights 

5.  Document  the  proposal  content  that  the  suppliers  must  submit  with 
their  response. 
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The  following  are  examples  of  proposal  content  for  suppliers  to  submit: 

:  •  Compliance  with  the  requirements 
i  •  References,  company  overview,  case  studies 

|  •  Evidence  of  the  supplier’s  organizational  processes  upon  which  the  supplier’s 
|  processes  for  the  project  will  be  based  and  the  commitment  to  execute  those 
■  processes  from  project  inception 

:  •  Plan  describing  how  the  potential  supplier  will  carry  out  the  scope  and  content  of 
the  solicitation  package,  including  any  improvement  of  execution  capability  over 
:  the  duration  of  the  supplier  agreement 

i  •  Understanding  of  the  size  and  complexity  of  the  requested  work  based  on  the 
i  requirements 

j  •  Pricing  and  compensation  which  typically  include: 

j  •  Pricing  and  compensation  methodology  that  provides  for  calculation  of  the 

charges  with  respect  to  the  services  being  provided  to  the  acquirer  pursuant  to  the 
supplier  agreement  and  terms  &  conditions,  including  taxes,  credits,  foreign 
currency  translation,  licenses,  pass-through  costs,  and  travel  reimbursements. 

i  •  Pricing  and  compensation  schedules  that  provide  for  the  charges  for  the  products 
and  services  provided,  including  frequency,  term,  and  pricing  type  (e.g.,  fixed 
:  price  lump  sum,  time  and  materials)  as  well  as  rate  cards,  and  skills  matrix. 

i  •  Acquirer’s  Travel  Reimbursement  policies 

j  •  References  and  experience  validating  the  capability  of  the  potential  supplier’s 
j  proposed  approach  to  meet  the  proposed  funding,  schedule,  and  quality  targets 

j  •  Risk  management  plan  describing  how  the  potential  supplier  will  identify  and 
manage  risks  associated  with  the  risks  called  out  in  the  solicitation  package 

i  •  Methods  for  early  defect  identification  and  the  prevention  of  defects  in  the 
products  delivered 

j  •  Supplier’s  approach  to  quality  assurance  of  the  product 
j  •  Approach  to  escalation  and  resolution  of  issues 

:  •  Description  of  the  potential  supplier’s  proposed  use  of  COTS  and  the  rationale  for 
:  the  supplier’s  confidence  that  the  use  of  COTS  can  achieve  the  requirements. 

:  •  Description  of  the  potential  supplier’s  proposed  re-use  of  previously  developed 
i  hardware  and  software,  and  the  rationale  for  the  supplier’s  confidence  that  the  re- 
i  use  can  be  achieved. 

j  •  Approach  to  provide  visibility  for  development  progress  and  costs  at  a  level 
j  appropriate  for  the  type  of  contract  and  commensurate  with  the  degree  of  risk 

:  •  Retention  of  critical  staff  during  the  project 

:  •  Identification  of  any  work  to  be  performed  by  subcontractors 

6.  Incorporate  acquirer’s  (standard)  supplier  agreement,  terms  and 
conditions,  and  additional  information  into  the  solicitation  package. 

Contract  terms  and  conditions,  typically  include  the  following: 

•  Recitals 
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•  Deliverables  and  Rights 

•  Compensation  and  payments 

•  Confidentiality 

•  Privacy  statements 

•  Continuous  improvement  and  best  practices 

•  Exclusive  services,  Key  Employees,  Supplier’s  Personnel  at  Acquirer’s  sites 

•  Information  Gathering  Practices  and  Ethical  Representation 

•  Force  Majeure 

•  Term 

•  Termination  for  Insolvency,  Breach  or  Non-performance 

•  Termination  for  Convenience 

•  Termination  Assistance 

•  Indemnification 

•  Insurance 

•  Right  to  Audit 

•  Notices 

Typical  considerations  for  additional  instructions  and  general  Information  for  the 
supplier  when  responding  to  the  solicitation  package  include  the  following: 

•  Submission  of  intent  to  submit  proposal 

•  Submission  due  date,  time,  and  destination 

•  Number  of  proposal  copies  that  must  be  submitted 

•  Proposal  format 

•  Non-complying  proposals 

•  Proposal  ownership 

•  Bidder  inquiries 

•  Key  dates  and  activities 

•  Discretionary  selection  and  potential  modifications  of  solicitation  process 

•  No  implied  offer 

•  Response  constitutes  an  offer  to  do  business 

•  Confidentiality  of  information 

•  Publicity 

•  Use  of  subcontractors 

•  Due  diligence 

•  Incurred  costs 

•  Language  and  statutory  units 
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SP  1.4  Review  the  Solicitation  Package 

Review  the  solicitation  package  with  stakeholders  to  make  sure 
the  approach  is  realistic  and  can  reasonably  lead  to  a  usable 
product. 


The  solicitation  package  is  reviewed  with  end  users  and  other 
stakeholders,  to  make  sure  the  requirements  have  been  accurately  and 
sufficiently  stated  so  that  the  solicitation  can  lead  to  a  manageable 
agreement.  The  acquirer  establishes  traceability  between  the 
requirements  and  the  solicitation  package.  Suppliers  may  be  included 
as  stakeholders  in  the  review  of  the  solicitation  package.  The  acquirer 
wants  the  solicitation  package  to  attract  a  variety  of  responses  and 
encourage  competition.  The  acquirer  also  wants  to  ensure  that  the 
package  is  legally  inclusive  of  all  qualified  suppliers. 

The  acquirer  may  use  standard  templates  and  checklists  to  verify  the 
necessary  components  (e.g.,  skills,  standards,  verification  and 
validation  methods,  measures  and  acceptance  criteria  are  covered  in 
the  solicitation  package). 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets. 

The  independent  cost  and  schedule  estimates  for  the  supplier’s  project 
work  developed  in  the  practice  above  are  also  reviewed. 

Typical  Acquirer  Work  Products 

1 .  Record  of  the  reviews  of  the  solicitation  package 

SP  1.5  Distribute  and  Maintain  Solicitation  Package 

Distribute  the  Solicitation  Package  to  potential  suppliers  for 
their  response  and  maintain  its  content  throughout  the 
solicitation. 


The  solicitation  package  is  distributed  to  the  potential  suppliers 
identified  above. 

The  acquirer  uses  the  Project  Planning  practices  and  the  Project 
Monitoring  and  Control  practices  to  monitor,  control,  and  replan  acquirer 
activities  during  the  solicitation  process  as  necessary. 

Typical  Acquirer  Work  Products 

1.  Potential  suppliers 

2.  Responses  to  supplier  questions 
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3.  Amendments  to  the  solicitation  package 

Typical  Supplier  Deliverables 

1.  Supplier  proposals 

2.  Supplier  questions,  requests  for  clarification 

Subpractices 

1 .  Finalize  list  of  potential  suppliers. 

2.  Distribute  solicitation  package  to  potential  suppliers. 

3.  Document  and  respond  to  supplier  questions  according  to  the 
instructions  in  the  solicitation  package. 

Verify  that  all  potential  suppliers  have  equal  access  and  opportunity  to  provide 
feedback  on  the  solicitation  package.  Provide  the  opportunity  for  the  selected 
potential  suppliers  and  stakeholders  to  clarify  points  of  ambiguity  in  the 
requirements  as  well  as  any  disconnects  or  concerns  with  the  requirements. 

4.  Acknowledge  the  receipt  of  supplier  proposals  according  to  the 
schedule  identified  in  the  solicitation  package. 

5.  Verify  the  conformance  to  requirements  and  completeness  of  the 
supplier  response.  Contact  suppliers  if  the  response  is  non- 
conforming  or  incomplete  for  corrective  action. 

6.  Issue  amendments  to  the  solicitation  package  when  changes  are 
made  to  the  solicitation. 


SG  2  Select  Suppliers 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet  the 
specified  requirements  and  established  criteria. 


SP  2.1  Evaluate  Proposed  Solutions 

Evaluate  proposed  solutions  according  to  the  documented 
proposal  evaluation  plans  and  criteria. 


Refer  to  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation  approaches  that  can  be  used  to 
select  suppliers. 

Proposals,  submitted  in  response  to  solicitation  packages,  are 
evaluated  in  accordance  with  an  overall  established  timeline,  and 
preliminary  project  plans  and  proposal  evaluation  criteria.  The  proposal 
evaluation  criteria  are  used  to  evaluate  the  potential  suppliers’ 
responses  to  the  solicitation.  Evaluation  results  and  decision  making 
notes  (e.g.,  advantages  and  disadvantages  of  potential  suppliers  and 
scoring  against  criteria)  should  be  documented  and  maintained. 
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The  acquirer  refines  the  negotiation  strategy  based  upon  the  evaluation 
of  the  suppliers’  proposals  and  the  evaluation  of  the  suppliers.  The 
proposal  evaluation  and  the  negotiations  with  the  suppliers  provide  the 
basis  for  selecting  a  supplier  best  able  to  meet  the  requirements  of  the 
solicitation. 

For  task  orders  or  contractual  changes  against  an  existing  supplier 
agreement,  the  acquirer  uses  documented  evaluation  criteria  against 
which  to  evaluate  the  task  order  responses  or  proposed  contractual 
changes.  In  a  sole  source  or  change  order  environment,  this  practice  is 
critical  for  relevant  stakeholders  to  understand  the  intent  of  the  effort  or 
changes  before  placing  the  additional  work  against  the  supplier 
agreement. 

Typical  Acquirer  Work  Products 

1 .  Clarification  correspondence  between  the  acquirer  and  potential 
suppliers 

2.  Evaluation  results  and  rationale 

3.  Candidate  suppliers 

Typical  Supplier  Deliverables 

1.  Proposal  revisions  based  upon  clarifications 

2.  Supplier  documentation  of  their  approach  to  the  project  work, 
capabilities,  preliminary  technical  solution 

Subpractices 

1 .  Distribute  supplier  proposals  to  the  individuals  identified  by  the 
acquirer  to  perform  the  evaluation. 

2.  Schedule  acquirer  evaluation  review  of  supplier  proposals  to 
consolidate  questions,  concerns  and  issues. 

3.  Schedule  supplier  presentations. 

4.  Verify  the  mutual  understanding  of  the  statement  of  work. 

A  good  practice  is  to  compare  the  supplier’s  estimates  to  those  developed  in  the 
project  planning  practices;  this  comparison  provides  a  means  to  determine  if  there 
is  a  mutual  understanding  of  the  requirements  and  the  associated  work  to  fulfill 
them. 

5.  Evaluate  supplier  proposals  and  document  findings. 

6.  Execute  due  diligence. 
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Due  diligence  provides  an  opportunity  for  the  acquirer  to  further  clarify 
requirements,  particularly  those  related  to  the  acquirer’s  existing  environment  and 
products  in  use.  The  potential  suppliers  ask  questions  and  gain  understanding, 
which  enables  them  to  make  their  proposals  more  realistic.  It  also  enables  the 
acquirer  to  gain  insight  into  the  capability  of  the  potential  suppliers’  proposed 
solutions  to  meet  requirements. 

Due  diligence  helps  to  eliminate  assumptions  and  replace  them  with  facts,  to 
identify  and  document  risks  and  their  mitigation  plans  or  effect  on  the  agreement, 
and  to  list  issues  and  dependencies  between  the  acquirer  and  supplier  to  include 
in  the  agreement. 


:  The  following  are  typical  examples  of  due  diligence  activities: 

:  •  Reviews  of  requirements  with  current  supplier  or  acquirer  resources  maintaining 
:  the  products  or  providing  services 

i  •  Reviews  of  interfaces  of  a  system  with  other  systems  maintained  by  the  acquirer 
|  •  Review  and  validation  of  supplier  references 
|  •  Reviews  of  operating  environment’s  facilities  and  capabilities 
:  •  Reviews  of  regulatory  and  security  requirements 
•  Reviews  of  supplier  capabilities 

7.  Document  candidate  supplier  recommendations  based  upon 
proposal  evaluation 

SP  2.2  Develop  Negotiation  Plans 

Develop  negotiation  plans  to  use  in  completing  a  supplier 
agreement. 


Develop  a  negotiation  plan  for  each  of  the  candidate  suppliers  based 
upon  evaluation  of  the  suppliers  and  their  proposals. 

The  size  of  a  negotiation  team  depends  upon  the  size  and  complexity  of 
the  project.  Typically  the  team  is  led  by  supplier  management  and  also 
includes  individuals  who  have  detailed  knowledge  of  the  statement  of 
work  documented  in  the  solicitation  package.  The  negotiation  team  is 
typically  supported  by  legal  staff,  a  financial  analyst,  purchasing  and  the 
project  manager  for  the  project. 
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Example  of  items  included  in  a  negotiation  strategy  include  the  following: 

•  Roles  and  responsibilities  of  negotiation  team  members 

•  Key  issues  to  be  negotiated  from  the  supplier  responses 

•  Negotiation  "levers,"  and  where  and  when  they  should  be  used 

•  Sequence  of  events  to  negotiate  the  issues 

•  Fall-back  or  compromise  positions  as  necessary  on  given  issues  (possible 
concessions  and  trades) 

•  List  of  items  that  are  non-negotiable 

•  External  factors  that  could  influence  the  negotiations;  (e.g.,  other  pending  deals, 
strategic  plans,  etc.) 

•  Prior  supplier  contracting  experiences  to  discover  previous  positions  and  issues 
(and  negotiating  styles) 

•  Schedule  and  sequence  for  supplier  negotiations  meetings 

•  Specific  objectives  for  each  negotiating  session 

•  Risks,  consequences  and  mitigation  alternatives 

Typical  Acquirer  Work  Products 

1 .  Negotiation  Strategy  for  candidate  suppliers 


SP  2.3  Finalize  Supplier  Selection 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet 
the  specified  requirements  and  established  criteria. 


Proposal  evaluation  results  are  used  to  finalize  a  supplier  selection 
based  on  the  outcome  of  negotiations.  The  negotiations  enable  the 
acquirer  to  select  the  best  supplier  for  the  project.  In  some  cases  the 
acquirer  may  take  the  top  two  proposals  and  use  negotiations  to  make 
the  final  selection  decision. 

The  evaluation  results,  along  with  the  negotiation  results,  support  the 
selection  decision  or  cause  the  acquirer  to  take  other  action  as 
appropriate.  If  the  return  on  investment  is  not  sufficient  the  acquirer  may 
decide  to  defer  or  cancel  the  project. 

Typical  Acquirer  Work  Products 

1 .  Revisions  due  to  negotiations 

2.  Supplier  sourcing  decision 
Subpractices 

1 .  Negotiate  with  supplier(s)  to  determine  best  fit  for  the  project. 


Solicitation  and  Supplier  Agreement  Development 


353 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


SG  3 


Negotiate  with  the  selected  supplier  or  candidate  suppliers  to  resolve  any  issues 
identified  during  due  diligence  and  to  address  any  remaining  issues  with 
requirements  and  revise  the  requirements  to  be  fulfilled  by  the  supplier. 

2.  Select  a  supplier  to  be  awarded  the  supplier  agreement. 

3.  Document  sourcing  decision 


Establish  Supplier  Agreements 

Establish  and  maintain  formal  agreements  with  selected  suppliers. 

A  formal  agreement  is  established  based  on  the  supplier  sourcing 
decision. 


SP  3.1  Establish  Mutual  Understanding  of  the  Agreement 

Establish  and  maintain  a  mutual  understanding  of  the  contract 
with  selected  suppliers  and  end  users  based  on  the  acquisition 
needs  and  the  suppliers’  proposed  approaches. 


As  points  of  clarification  and  ambiguities  continue  to  arise  after  contract 
award,  ensure  the  mutual  understanding  is  revised  and  maintained 
through  the  life  of  the  project.  Ensure  that  the  supplier  makes  a 
contractual  commitment  to  execute  its  proposed  processes. 

Typical  Acquirer  Work  Products 

1 .  Correspondence  clarifying  elements  of  the  agreement 

2.  Frequently  asked  questions  (for  use  with  end  users,  other 
suppliers) 


SP  3.2  Document  Supplier  Agreement 

Document  approved  supplier  agreement 


The  agreement  may  be  either  a  stand-alone  agreement  or  part  of  a 
master  agreement.  When  part  of  a  master  agreement,  the  project  may 
be,  for  instance,  an  addendum,  work  order,  or  service  request  to  the 
master  agreement. 

Typical  Acquirer  Work  Products 

1 .  Supplier  agreement  (including  terms  &  conditions) 

Subpractices 

1 .  Document  the  supplier  agreement  for  the  project. 

The  supplier  agreement  provisions  typically  include  the  following: 

•  The  statement  of  work,  specification,  terms  and  conditions,  list  of  deliverables, 
schedule,  budget,  and  acceptance  process 

•  Product  acceptance  criteria  to  be  satisfied  by  the  supplier 
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•  Statement  of  work  for  the  supplier 

•  Measurements  and  reports  that  provide  the  acquirer  visibility  into  the  supplier’s 
process  and  results 

•  Mechanisms  and  deliverables  that  provide  the  acquirer  sufficient  data  to  allow 
evaluation  and  analysis  of  acquired  products 

•  Who  from  the  project  and  supplier  are  responsible  and  authorized  to  make 
changes  to  the  supplier  agreement 

•  Supplier's  responsibility  for  supporting  business  acceptance  working  with  the 
acquirer 

•  How  requirements  changes  and  changes  to  the  supplier  agreement  are 
determined,  communicated,  and  addressed 

•  Standards  and  procedures  that  will  be  followed  (e.g.,  configuration  management, 
escalation,  non-conformances,  conflicts,  issues,  etc.) 

•  Requirements  for  the  supplier  to  establish  a  corrective  action  system  that  includes 
a  change  control  process  for  rework  and  reevaluation 

•  Critical  dependencies  between  the  acquirer  and  the  supplier 

•  Documentation  of  what  the  acquirer  will  provide  to  the  supplier  such  as  facilities, 
tools,  software,  documentation  and  services 

•  Verification  methods  and  acceptance  criteria  for  designated  supplier  deliverables. 

•  The  type  and  depth  of  project  oversight  of  the  supplier  procedures  and  evaluation 
criteria  to  be  used  in  monitoring  supplier  performance 

•  The  types  of  reviews  that  will  be  conducted  with  the  supplier 

•  The  supplier’s  responsibilities  to  execute  corrective  actions  when  initiated  by  the 
Project  Monitoring  and  Control  practices 

•  Non-hire  and  non-compete  clauses 

•  Confidentiality,  non-disclosure,  intellectual  capital  clauses  pertaining  to  PPQA, 
Measurement  Data,  personnel  who  would  perform  audits  or  are  authorized  to 
validate  measurement  data. 

•  The  supplier’s  responsibilities  for  preparation  of  the  site  and  training  of  the  support 
and  operations  organizations  according  to  acquirer  specified  standards,  tools  and 
methods. 

•  The  supplier’s  responsibilities  for  ongoing  maintenance  and  support  of  the 
acquired  products 

•  Requirements  for  the  supplier  to  be  involved  in  the  deployment  of  process  assets 
as  necessary 

•  Warranty,  ownership,  and  usage  rights  for  the  acquired  products 

•  Security  and  legal  penalty  recoveries 

3.  Verify  that  all  parties  to  the  agreement  understand  and  agree  to  all 

requirements  by  signing  the  supplier  agreement. 

4.  Notify  those  suppliers  not  selected  for  the  award. 
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Refer  to  Organizational  Process  Definition  for  organizational 
guidelines  on  communication  to  suppliers  not  selected  for  the 
agreement. 

5.  Communicate  the  supplier  agreement  within  the  organization  as 
required. 


356 


Solicitation  and  Supplier  Agreement  Development 


Part  Three 

The  Appendices  and  Glossary 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Appendix  A:  References 


Publicly  Available  Sources 


Ahern  2005 


Curtis  2002 


Deming  1986 


EIA1994 

El  A  1998 


Humphrey  1989 


IEEE  1990 


ISO  1987 


ISO  1995 


Ahern,  Dennis  M.;  Armstrong  Jim;  Clouse,  Aaron;  Ferguson, 
Jack;  Hayes,  Will;  and  Nidiffer,  Kenneth.  CMMI  SCAMPI 
Distilled:  Appraisals  for  Process  Improvement.  Boston: 
Addison  Wesley,  2005. 

Curtis,  Bill;  Hefley,  William  E.;  and  Miller,  Sally  A.  The 
People  Capability  Maturity  Model  Guidelines  for  Improving 
the  Workforce.  Boston:  Addison-Wesley,  2002. 

Deming,  W.  Edwards.  Out  of  the  Crisis.  Cambridge,  MA: 

MIT  Center  for  Advanced  Engineering,  1986. 

Electronic  Industries  Alliance.  El  A  Interim  Standard: 
Systems  Engineering  (EIA/IS-632).  Washington,  DC,  1994. 

Electronic  Industries  Alliance.  Systems  Engineering 
Capability  Model  (EIA/IS-731).  Washington,  DC,  1998. 
<http://geia.org/sstc/G47/731dwnld.htm> 

Humphrey,  Watts  S.  Managing  the  Software  Process. 
Reading,  MA:  Addison-Wesley,  1989. 

Institute  of  Electrical  and  Electronics  Engineers.  IEEE 
Standard  Computer  Dictionary:  A  Compilation  of  IEEE 
Standard  Computer  Glossaries.  New  York:  IEEE,  1990. 

International  Organization  for  Standardization.  ISO  9000: 
International  Standard.  New  York,  1987. 
<http://www.iso.ch/> 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  TR 
12207  Information  Technology — Software  Life  Cycle 
Processes,  1995. 

<  www.jtd-sc7.org  > 


358 


References 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


ISO  2000 


ISO  2002 


ISO  2006 


Juran  1988 


SEI  1995 


SEI  1997 


SEI  2002 


Shewhart  1931 


International  Organization  for  Standardization.  ISO  9001, 
Quality  Management  Systems — Requirements,  2000. 
<http://www.iso.ch/> 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  15288 
Systems  Engineering — System  Life  Cycle  Processes,  2002. 
<http://www.jtd  -sc7.org/> 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission.  ISO/IEC  TR 
15504  Information  Technology — Software  Process 
Assessment  Part  1:  Concepts  and  vocabulary,  Part  2: 
Performing  an  Assessment,  Part  3:  Guidance  on  Performing 
an  Assessment,  Part  4:  Guidance  on  use  for  process 
improvement  and  process  capability  determination,  Part  5: 
An  exemplar  Process  Assessment  Model,  2003-2006. 
<http://www.jtd-sc7.org/> 

Juran,  J.  M.  Juran  on  Planning  for  Quality.  New  York: 
Macmillan,  1988. 

Software  Engineering  Institute.  The  Capability  Maturity 
Model:  Guidelines  for  Improving  the  Software  Process. 
Reading,  MA:  Addison-Wesley,  1995. 

Integrated  Product  Development  Capability  Maturity  Model, 
Draft  Version  0.98.  Pittsburgh,  PA:  Enterprise  Process 
Improvement  Collaboration  and  Software  Engineering 
Institute,  Carnegie  Mellon  University,  July  1997. 
<ftp://ftp.sei.cmu.edu/pub/CMMI/ipd-cmm-draft/> 

Software  Engineering  Institute.  Software  Acquisition 
Capability  Maturity  Model  (SA-CMM)  Version  1.03 
( CMU/SEI-2002-TR-01 0,  ESC-TR-2002-01 0).  Pittsburgh, 

PA:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  March  2002. 

<http://www.sei.cmu.edu/publications/documents/02.reports/ 

02tr010.html> 

Shewhart,  Walter  A.  Economic  Control  of  Quality  of 
Manufactured  Product.  New  York:  Van  Nostrand,  1931. 


References 


359 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


Regularly  Updated  Sources 


SEI  1  Software  Engineering  Institute.  Transitioning  Your 

Organization  from  Software  CMM  Version  1.1  to  CMMI-SW 
Version  1.0. 

<http://www.sei.cmu.edu/cmmi/publications/white- 

paper.html> 

SEI  2  Software  Engineering  Institute.  The  IDEAL  Model. 

<http://www.sei.cmu.edu/ideal/ideal.html> 

SEI  3  Software  Engineering  Institute.  Advice  for  Change  Agents. 

<http://www.sei.cmu.edu/asta/advice.html> 


360 


References 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 

Appendix  B:  Acronyms 


AM 

Acquisition  Management  (process  area) 

ARC 

Appraisal  requirements  for  CMMI 

ARD 

Acquisition  Requirements  Development  (process  area) 

ATS 

Acquisition  Technical  Solution  (process  area) 

AVAL 

Acquisition  Validation  (process  area) 

AVER 

Acquisition  Verification  (process  area) 

CAD 

computer-aided  design 

CAR 

Causal  Analysis  and  Resolution  (process  area) 

CCB 

configuration  control  board 

CL 

capability  level 

CM 

Configuration  Management  (process  area) 

CMM 

Capability  Maturity  Model 

CMMI 

Capability  Maturity  Model  Integration 

CMMI-DEV 

CMMI  for  Development 

CMMI-DEV+IPPD 

CMMI  for  Development  with  IPPD 

COTS 

commercial  off  the  shelf 

CPI 

cost  performance  index 

CPM 

critical  path  method 

CSCI 

computer  software  configuration  item 

DAR 

Decision  Analysis  and  Resolution  (process  area) 

DoD 

Department  of  Defense 
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EIA 

EIA/IS 

EPG 

FCA 

GG 

GP 

IBM 

IDEAL 

IEEE 

INCOSE 

IPD-CMM 

IPM 

IPM+IPPD 

IPPD 

IPT 

ISO 

ISO/IEC 

MA 

MDD 

MOA 

ML 

NDI 

NDIA 

OID 

OPD 


Electronic  Industries  Alliance 

Electronic  Industries  Alliance  Interim  Standard 

engineering  process  group 

functional  configuration  audit 

generic  goal 

generic  practice 

International  Business  Machines 

Initiating,  Diagnosing,  Establishing,  Acting,  Learning 

Institute  of  Electrical  and  Electronics  Engineers 

International  Council  on  Systems  Engineering 

Integrated  Product  Development  Capability  Maturity  Model 

Integrated  Project  Management  (process  area) 

Integrated  Project  Management  with  IPPD  (process  area) 

integrated  product  and  process  development 

integrated  product  team 

International  Organization  for  Standardization 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission 

Measurement  and  Analysis  (process  area) 

method  definition  document 

memorandum  of  agreement 

maturity  level 

nondevelopmental  item 

National  Defense  Industrial  Association 

Organizational  Innovation  and  Deployment  (process  area) 

Organizational  Process  Definition  (process  area) 
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OPD+IPPD 

Organizational  Process  Definition  with  IPPD  (process 
area) 

OPF 

Organizational  Process  Focus  (process  area) 

OPP 

Organizational  Process  Performance  (process  area) 

OT 

Organizational  Training  (process  area) 

OUSD  (AT&L) 

Office  of  the  Under  Secretary  of  Defense  (Acquisition, 
Technology,  and  Logistics) 

P-CMM 

People  Capability  Maturity  Model 

PA 

process  area 

PCA 

physical  configuration  audit 

PERT 

Program  Evaluation  and  Review  Technique 

PI 

Product  Integration  (process  area) 

PMC 

Project  Monitoring  and  Control  (process  area) 

PP 

Project  Planning  (process  area) 

PPQA 

Process  and  Product  Quality  Assurance  (process  area) 

QA 

quality  assurance 

QFD 

Quality  Function  Deployment 

QPM 

Quantitative  Project  Management  (process  area) 

RD 

Requirements  Development  (process  area) 

REQM 

Requirements  Management  (process  area) 

ROI 

return  on  investment 

RSKM 

Risk  Management  (process  area) 

SA-CMM 

Software  Acquisition  Capability  Maturity  Model 

SAM 

Supplier  Agreement  Management  (process  area) 

SCAMPI 

Standard  CMMI  Appraisal  Method  for  Process 
Improvement 

SECM 

Systems  Engineering  Capability  Model 
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SEI 

Software  Engineering  Institute 

SG 

specific  goal 

SP 

specific  practice 

SPI 

schedule  performance  index 

SSAD 

Solicitation  and  Supplier  Agreement  Development 
(process  area) 

SW-CMM 

Capability  Maturity  Model  for  Software  or  Software 
Capability  Maturity  Model 

TS 

Technical  Solution  (process  area) 

URL 

Uniform  Resource  Locator 

VAL 

Validation  (process  area) 

VER 

Verification  (process  area) 

WBS 

work  breakdown  structure 
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Appendix  C:  Adapting  CMMI  for  Acquisition 
Organizations  Project  Participants 


Many  talented  people  were  part  of  the  product  team  that  created  the 
initial  draft  CMMI-ACQ.  The  three  primary  groups  involved  in  this 
development  have  been  the  primary  development  team,  the  review 
participants,  and  the  CMMI  Steering  Group. 


Primary  Development  Team 


The  primary  development  team  wrote  and  revised  the  structure  and 
technical  content  of  this  document.  Development  activities  were  based 
on  an  A-Specification  and  CMMI  Framework,  provided  by  the  Steering 
Group,  two  source  models,  one  source  module,  and  comments  from 
reviewers,  stakeholders,  and  Steering  Group  members. 
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Kathryn  M.  Dodson,  EDS 
Dr.  Hubert  F.  Hofmann,  General  Motors 
Gowri  S.  Ramani,  Hewlett  Packard 
Deborah  K.  Yedlin,  General  Motors 
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Accenture  Ltd. 
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Best  Practice  Implementations,  LLC 

Singh,  Roz 

Cap  Gemini 

MacDonald,  Doug 
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EDS _ 

Adler,  Stu 
Bialk,  Kelly 
Bilger,  Mark 
Niles,  Gail 
Phifer,  Bill 
Sawyer,  Jodie 

General  Motors  Corporation 

Brown,  Michele 
Chen,  Helen 
Chodnicki,  Darin 
Gonzalvo,  Zahira 
Khan,  Assif 
King,  Carla 
Konda,  Damodar 
Long,  Earl  Jr. 
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Mahlebashian,  Daniel 
Mecklenburg,  Karsten 
Murthy,  Bala 
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Page,  Dennis 
Slykhouse,  Roger 
Steele,  Christopher 
Wright,  Craig 
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Hewlett-Packard  Company 

Channaveer,  Patil 
Gurumurthy,  Ashok 
Henrichs,  Debra 
Kaliappan,  Marappa 
Mohan,  Mythili 
Murthy,  Gangadhar 
Naumann,  Karl 
Pais,  Eric-A 
Sundar,  Gayatri 
Swaminathan,  Murli 

IBM _ 

McLachlan,  Tim 
Yu,  Chung 

Infosys 

Kumars,  Aman 

Lucent  Technologies 

Chellappa,  Mallika 

Moksha  Technologies 

Vijayan,  Ajita 

NASA _ 

Niles,  Charles 

Northrop  Grumman  Corporation 

Wilson,  Hal 

Onstar 

Ottoson,  Robert 

Satyam 

Khendry,  Anu 

Science  Applications  International  Corporation 

Pyster,  Arthur 

Support  Systems  Associates,  Inc. 

Jones,  James 
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Tata  Consultancy  Services  Limited 

Keeni,  Gangi 

TPI _ 

Creamer,  Frank 
Stout,  Bill 

US  Army 

D’Agosto,  Tony 

US  Defense  Department 

Baldwin,  Kristen 
Richter,  Karen 

US  Navy _ 

Zettervall,  Brenda 

Wipro  Technologies 

Banavar,  Thara 


Steering  Group 


The  Steering  Group  has  guided  and  approved  the  plans  of  the  Product 
Team,  provided  consultation  on  significant  CMMI  project  issues,  and 
ensured  involvement  from  a  variety  of  interested  communities. 

Steering  Group  Members 

Baldwin,  Kristen  (OUSD  [AT&L]  DS/SE) 

Chittister,  Clyde  (Software  Engineering  Institute) 

D’Agosto,  Tony  (US  Army  RDECOM-ARDEC) 

Gill,  Jim  (Boeing  Integrated  Defense  Systems) 

Kelly,  John  (NASA  HQ) 

Lundeen,  Kathy  (Defense  Contract  Management  Agency) 

McCarthy,  Larry  (Motorola,  Inc.) 

Nicol,  Mike  (US  Air  Force  ASC/EN) 

Peterson,  Bill  (Software  Engineering  Institute) 

Rassa,  Bob  (Raytheon  Space  &  Airborne  Systems) 

Sumpter,  Beth  (National  Security  Agency) 

Weszka,  Joan  (Lockheed  Martin) 

Wilson,  Hal  (Northrop  Grumman  Mission  Systems) 
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Ex  Officio  Steering  Group  Members 

Anderson,  Lloyd  (Department  of  Homeland  Security) 

Bate,  Roger,  chief  architect  (Software  Engineering  Institute) 

Drake,  Thomas  (National  Security  Agency) 

Phillips,  Mike,  CMMI  project  manager  (Software  Engineering  Institute) 
Yedlin,  Debbie  (General  Motors) 
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Appendix  D:  Glossary 


The  glossary  defines  the  basic  terms  used  in  CMMI  models.  Glossary 
entries  are  typically  multiple-word  terms  consisting  of  a  noun  and  one  or 
more  restrictive  modifiers.  (There  are  some  exceptions  to  this  rule  that 
account  for  one-word  terms  in  the  glossary.) 

To  formulate  definitions  appropriate  for  CMMI  models,  we  consult 
multiple  sources.  We  first  consult  Webster's  Online  dictionary  (www.m- 
w.com)  and  the  source  models  (i.e.,  CMMI  vl  .2,  EIA  731 ,  SW-CMM  v2, 
draft  C,  and  IPD-CMM  v0.98).  We  also  consult  other  standards  as 
needed,  including  the  following: 

•  ISO  9000  [ISO  1987] 

•  ISO/I  EC  12207  [ISO  1995] 

•  ISO/I  EC  15504  [ISO  2006] 

•  ISO/I  EC  15288  [ISO  2002] 

•  IEEE  [IEEE  1990] 

•  SW-CMM  vl  .1 

•  EIA  632  [EIA  1994] 

•  SA-CMM  [SEI  2002] 

•  P-CMM  [Curtis  2002] 

We  developed  the  glossary  recognizing  the  importance  of  using 
terminology  that  all  model  users  can  understand.  We  also  recognized 
that  words  and  terms  can  have  different  meanings  in  different  contexts 
and  environments.  The  glossary  in  CMMI  models  is  designed  to 
document  the  meanings  of  words  and  terms  that  should  have  the  widest 
use  and  understanding  by  users  of  CMMI  products. 

acceptance  criteria  The  criteria  that  a  product  or  product  component  must 

satisfy  to  be  accepted  by  a  user,  customer,  or  other 
authorized  entity. 

acceptance  testing  Formal  testing  conducted  to  enable  a  user,  customer,  or 

other  authorized  entity  to  determine  whether  to  accept  a 
product  or  product  component.  (See  also  “unit  testing.”) 
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achievement  profile 

acquisition 
acquisition  strategy 

adequate 

agreement/contract 

requirements 

allocated 

requirement 

alternative  practice 

appraisal 

appraisal  findings 


In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  the 
organization’s  progress  for  each  process  area  while 
advancing  through  the  capability  levels.  (See  also 
“capability  level  profile,”  “target  profile,”  and  “target 
staging.”) 

The  process  of  obtaining  products  (goods  and  services) 
through  contract. 

The  specific  approach  to  acquiring  products  and  services 
that  is  based  on  considerations  of  supply  sources, 
acquisition  methods,  requirements  specification  types, 
contract  or  agreement  types,  and  the  related  acquisition 
risk. 

This  word  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  of  the  time.  (See  also  “appropriate”  and  “as 
needed.”) 

All  technical  and  nontechnical  requirements  related  to  an 
acquisition. 

Requirement  that  levies  all  or  part  of  the  performance  and 
functionality  of  a  higher  level  requirement  on  a  lower  level 
architectural  element  or  design  component. 

A  practice  that  is  a  substitute  for  one  or  more  generic  or 
specific  practices  contained  in  CMMI  models  that  achieves 
an  equivalent  effect  toward  satisfying  the  generic  or  specific 
goal  associated  with  model  practices.  Alternative  practices 
are  not  necessarily  one-for-one  replacements  for  the 
generic  or  specific  practices. 

In  the  CMMI  Product  Suite,  an  examination  of  one  or  more 
processes  by  a  trained  team  of  professionals  using  an 
appraisal  reference  model  as  the  basis  for  determining 
strengths  and  weaknesses.  (See  also  “assessment”  and 
“capability  evaluation.”) 

The  conclusions  of  an  appraisal  that  identify  the  most 
important  issues,  problems,  or  opportunities  within  the 
appraisal  scope.  Findings  include,  at  a  minimum,  strengths 
and  weaknesses  based  on  valid  observations. 
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appraisal 

participants 

appraisal  rating 


appraisal  reference 
model 


appraisal  scope 


appraisal  tailoring 


appraisal  team 
leader 


appropriate 


as  needed 


Members  of  the  organizational  unit  who  participate  in 
providing  information  during  the  appraisal. 

As  used  in  CMMI  appraisal  materials,  the  value  assigned  by 
an  appraisal  team  to  (1 )  a  CMMI  goal  or  process  area,  (2) 
the  capability  level  of  a  process  area,  or  (3)  the  maturity 
level  of  an  organizational  unit.  The  rating  is  determined  by 
enacting  the  defined  rating  process  for  the  appraisal  method 
being  employed. 

As  used  in  CMMI  appraisal  materials,  the  CMMI  model  to 
which  an  appraisal  team  correlates  implemented  process 
activities. 

The  definition  of  the  boundaries  of  the  appraisal 
encompassing  the  organizational  limits  and  the  CMMI 
model  limits. 

Selection  of  options  within  the  appraisal  method  for  use  in  a 
specific  instance. 

The  intent  of  appraisal  tailoring  is  to  assist  an  organization 
in  aligning  application  of  the  method  with  its  business 
objectives. 

A  person  who  leads  the  activities  of  an  appraisal  and  has 
satisfied  the  qualification  criteria  for  experience,  knowledge, 
and  skills  defined  by  the  appraisal  method. 

This  word  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  of  the  time.  (See  also  “adequate”  and  “as 
needed.”) 

This  phrase  is  used  so  that  you  can  interpret  goals  and 
practices  in  light  of  your  organization’s  business  objectives. 
When  using  any  CMMI  model,  you  must  interpret  the 
practices  so  that  they  work  for  your  organization.  This  term 
is  used  in  goals  and  practices  where  certain  activities  may 
not  be  done  all  the  time.  (See  also  “adequate”  and 
“appropriate.”) 
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assignable  cause  of 
process  variation 


audit 


base  measure 


baseline 


bidirectional 

traceability 


business  objectives 
capability  evaluation 


capability  level 


In  the  CMMI  Product  Suite,  an  appraisal  that  an 
organization  does  internally  for  the  purposes  of  process 
improvement.  The  word  assessment  is  also  used  in  the 
CMMI  Product  Suite  in  an  everyday  English  sense  (e.g.,  risk 
assessment).  (See  also  “appraisal”  and  “capability 
evaluation.”) 

In  CMMI,  the  term  special  cause  of  process  variation  is 
used  in  place  of  assignable  cause  of  process  variation  to 
ensure  consistency.  The  two  terms  are  defined  identically. 
(See  “special  cause  of  process  variation.”) 

In  CMMI  process  improvement  work,  an  objective 
examination  of  a  work  product  or  set  of  work  products 
against  specific  criteria  (e.g.,  requirements). 

A  distinct  property  or  characteristic  of  an  entity  and  the 
method  for  quantifying  it.  (See  also  “derived  measures.”) 

A  set  of  specifications  or  work  products  that  has  been 
formally  re-viewed  and  agreed  on,  which  thereafter  serves 
as  the  basis  for  further  development,  and  which  can  be 
changed  only  through  change  control  procedures  (See  also 
“configuration  baseline”  and  “product  baseline.”) 

An  association  among  two  or  more  logical  entities  that  is 
discernable  in  either  direction  (i.e.,  to  and  from  an  entity). 
(See  also  “requirements  traceability”  and  “traceability.”) 

(See  “organization’s  business  objectives.”) 

An  appraisal  by  a  trained  team  of  professionals  used  as  a 
discriminator  to  select  suppliers,  for  contract  monitoring,  or 
for  incentives.  Evaluations  are  used  to  help  decision  makers 
make  better  acquisition  decisions,  improve  subcontractor 
performance,  and  provide  insight  to  a  purchasing 
organization.  (See  also  “appraisal”  and  “assessment.”) 

Achievement  of  process  improvement  within  an  individual 
process  area.  A  capability  level  is  defined  by  the  appropriate 
specific  and  generic  practices  for  a  process  area.  (See  also 
“generic  goal,”  “generic  practice,”  “maturity  level,”  and 
“process  area.”) 
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capability  maturity 
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CMMI  Framework 


CMMI  model 


CMMI  model 
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In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels.  (See  also 
“achievement  profile,”  “target  profile,”  and  “target  staging.”) 

The  profile  may  be  an  achievement  profile  when  it 
represents  the  organization’s  progress  for  each  process 
area  while  advancing  through  the  capability  levels.  Or,  the 
profile  may  be  a  target  profile  when  it  represents  an 
objective  for  process  improvement. 

A  model  that  contains  the  essential  elements  of  effective 
processes  for  one  or  more  disciplines  and  describes  an 
evolutionary  improvement  path  from  ad  hoc,  immature 
processes  to  disciplined,  mature  processes  with  improved 
quality  and  effectiveness. 

A  process  that  can  satisfy  its  specified  product  quality, 
service  quality,  and  process-performance  objectives.  (See 
also  “stable  process,”  “standard  process,”  and  “statistically 
managed  process.”) 

The  analysis  of  defects  to  determine  their  cause. 

Judicious  use  of  means  to  effect  a  change,  or  proposed 
change,  on  a  product  or  service.  (See  also  “configuration 
management.”) 

The  basic  structure  that  organizes  CMMI  components, 
including  common  elements  of  the  current  CMMI  models  as 
well  as  rules  and  methods  for  generating  models,  their 
appraisal  methods  (including  associated  artifacts),  and  their 
training  materials.  The  framework  enables  new  disciplines 
to  be  added  to  CMMI  so  that  the  new  disciplines  will 
integrate  with  the  existing  ones.  (See  also  “CMMI  model” 
and  “CMMI  Product  Suite.”) 

One  from  the  entire  collection  of  possible  models  that  can 
be  generated  from  the  CMMI  Framework.  Since  the  CMMI 
Framework  can  generate  different  models  based  on  the 
needs  of  the  organization  using  it,  there  are  multiple  CMMI 
models.  (See  also  “CMMI  Framework”  and  “CMMI  Product 
Suite.”) 

Any  of  the  main  architectural  elements  that  compose  a 
CMMI  model.  Some  of  the  main  elements  of  a  CMMI  model 
include  specific  practices,  generic  practices,  specific  goals, 
generic  goals,  process  areas,  capability  levels,  and  maturity 
levels. 
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CMMI  model 
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process  variation 
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configuration  audit 


configuration 

baseline 


configuration 

control 


configuration 
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The  use  of  a  subset  of  a  CMMI  model  for  the  purpose  of 
making  it  suitable  for  a  specific  application.  The  intent  of 
model  tailoring  is  to  assist  an  organization  in  aligning 
application  of  a  model  with  its  business  objectives. 

The  complete  set  of  products  developed  around  the  CMMI 
concept.  These  products  include  the  framework  itself, 
models,  appraisal  methods,  appraisal  materials,  and  various 
types  of  training.  (See  also  “CMMI  Framework"  and  “CMMI 
model.”) 

The  variation  of  a  process  that  exists  because  of  normal 
and  expected  interactions  among  the  components  of  a 
process.  (See  also  “special  cause  of  process  variation.”) 

(See  “operational  concept.”) 

An  audit  conducted  to  verify  that  a  configuration  item,  or  a 
collection  of  configuration  items  that  make  up  a  baseline, 
conforms  to  a  specified  standard  or  requirement.  (See  also 
“audit,”  “configuration  item,”  “functional  configuration  audit,” 
and  “physical  configuration  audit,”) 

The  configuration  information  formally  designated  at  a 
specific  time  during  a  product’s  or  product  component’s  life. 
Configuration  baselines,  plus  approved  changes  from  those 
baselines,  constitute  the  current  configuration  information. 
(See  also  “product  life  cycle.”) 

An  element  of  configuration  management  consisting  of  the 
evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  changes  to  configuration  items  after 
formal  establishment  of  their  configuration  identification. 
(See  also  “configuration  identification,”  “configuration  item," 
and  “configuration  management.”) 

A  group  of  people  responsible  for  evaluating  and  approving 
or  disapproving  proposed  changes  to  configuration  items, 
and  for  ensuring  implementation  of  approved  changes.  (See 
also  “configuration  item.”) 

Configuration  control  boards  are  also  known  as  change 
control  boards. 
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An  element  of  configuration  management  consisting  of 
selecting  the  configuration  items  for  a  product,  assigning 
unique  identifiers  to  them,  and  recording  their  functional  and 
physical  characteristics  in  technical  documentation.  (See 
also  “configuration  item,”  “configuration  management,”  and 
“product.”) 

An  aggregation  of  work  products  that  is  designated  for 
configuration  management  and  treated  as  a  single  entity  in 
the  configuration  management  process.  (See  also 
“configuration  management.”) 

A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics,  (3)  record  and 
report  change  processing  and  implementation  status,  and 
(4)  verify  compliance  with  specified  requirements.  (See  also 
“configuration  audit,”  “configuration  control,”  “configuration 
identification,”  and  “configuration  status  accounting.”) 

An  element  of  configuration  management  consisting  of  the 
recording  and  reporting  of  information  needed  to  manage  a 
configuration  effectively.  This  information  includes  a  listing 
of  the  approved  configuration  identification,  the  status  of 
proposed  changes  to  the  configuration,  and  the 
implementation  status  of  approved  changes.  (See  also 
“configuration  identification”  and  “configuration 
management.”) 

A  capability  maturity  model  structure  wherein  capability 
levels  provide  a  recommended  order  for  approaching 
process  improvement  within  each  specified  process  area. 
(See  also  “capability  level,”  “process  area,”  and  “staged 
representation.”) 

(See  "supplier.") 

Acts  or  deeds  used  to  remedy  a  situation,  remove  an  error, 
or  adjust  a  condition. 

Items  that  can  be  purchased  from  a  commercial  vendor. 
(COTS  stands  for  “commercial  off  the  shelf.”) 
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The  party  (individual,  project,  or  organization)  responsible 
for  accepting  the  product  or  for  authorizing  payment.  The 
customer  is  external  to  the  project  (except  possibly  when 
Integrated  Product  Teams  are  used,  as  in  IPPD),  but  not 
necessarily  external  to  the  organization.  The  customer  may 
be  a  higher  level  project.  Customers  are  a  subset  of 
stakeholders.  (See  also  “stakeholder.”) 

The  meaning  of  the  term  “customer”  in  CMMI  is  context 
sensitive.  Therefore,  sometimes  the  narrow  definition  above 
is  intended,  but  other  times  a  more  broad  definition  of 
customer  is  used  that  may  include  other  relevant 
stakeholders  (e.g.,  as  in  the  phrase  “customer 
requirements”  used  in  the  Acquisition  Requirements 
Development  process  area). 

Recorded  information,  regardless  of  the  form  or  method  of 
recording,  including  technical  data,  computer  software 
documents,  financial  information,  management  information, 
representation  of  facts,  numbers,  or  datum  of  any  nature 
that  can  be  communicated,  stored,  and  processed. 

The  disciplined  processes  and  systems  that  plan  for, 
acquire,  and  provide  stewardship  for  business  and  technical 
data,  consistent  with  data  requirements,  throughout  the  data 
lifecycle. 

Number  of  defects  per  unit  of  product  size  (e.g.,  problem 
reports  per  thousand  lines  of  code). 

A  managed  process  that  is  tailored  from  the  organization’s 
set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description; 
and  contributes  work  products,  measures,  and  other 
process  improvement  information  to  the  organizational 
process  assets.  (See  also  “managed  process.”) 

Data  resulting  from  the  mathematical  function  of  two  or 
more  base  measures.  (See  also  “base  measure.”) 

Requirements  that  are  not  explicitly  stated  in  the  customer 
requirements,  but  are  inferred  (1)  from  contextual 
requirements  (e.g.,  applicable  standards,  laws,  policies, 
common  practices,  and  management  decisions),  or  (2)  from 
requirements  needed  to  specify  a  product  component. 
Derived  requirements  can  also  arise  during  analysis  and 
design  of  components  of  the  product  or  system.  (See  also 
“product  requirements.”) 
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A  formal,  documented,  comprehensive,  and  systematic 
examination  of  a  design  to  evaluate  the  design 
requirements  and  the  capability  of  the  design  to  meet  these 
requirements,  and  to  identify  problems  and  propose 
solutions. 

In  the  CMMI  Product  Suite,  not  only  development  activities 
but  also  maintenance  activities  may  be  included.  Projects 
that  benefit  from  the  best  practices  of  CMMI  can  focus  on 
development,  maintenance,  or  both. 

A  plan  for  guiding,  implementing,  and  controlling  the  design 
and  development  of  one  or  more  products.  (See  also 
“product  life  cycle”  and  “project  plan.”) 

In  the  CMMI  Product  Suite,  the  bodies  of  knowledge 
available  to  you  when  selecting  a  CMMI  model  (e.g., 
systems  engineering).  The  CMMI  Product  Team  envisions 
that  other  bodies  of  knowledge  will  be  integrated  into  the 
CMMI  Framework  in  the  future. 

Discipline  amplifications  are  informative  model  components 
that  contain  information  relevant  to  a  particular  discipline. 
For  example,  to  find  a  discipline  amplification  for  software 
engineering,  you  would  look  in  the  model  for  items  labeled 
“For  Software  Engineering.”  The  same  is  true  for  other 
disciplines. 

A  collection  of  data,  regardless  of  the  medium  on  which  it  is 
recorded,  that  generally  has  permanence  and  can  be  read 
by  humans  or  machines.  So,  documents  include  both  paper 
and  electronic  documents. 

The  full  composition  of  companies.  Companies  may  consist 
of  many  organizations  in  many  locations  with  different 
customers.  (See  also  “organization.”) 

States  of  being  that  must  be  present  before  an  effort  can 
begin  successfully. 
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A  target  staging,  created  using  the  continuous 
representation,  that  is  defined  so  that  the  results  of  using 
the  target  staging  can  be  compared  to  the  maturity  levels  of 
the  staged  representation.  (See  also  “capability  level 
profile,”  “maturity  level,”  “target  profile,"  and  “target 
staging.”) 

Such  staging  permits  benchmarking  of  progress  among 
organizations,  enterprises,  and  projects,  regardless  of  the 
CMMI  representation  used.  The  organization  may 
implement  components  of  CMMI  models  beyond  those 
reported  as  part  of  equivalent  staging.  Equivalent  staging  is 
only  a  measure  to  relate  how  the  organization  is  compared 
to  other  organizations  in  terms  of  maturity  levels. 

In  the  CMMI  Product  Suite,  you  will  encounter  goals  and 
practices  that  include  the  phrase  “establish  and  maintain.” 
This  phrase  means  more  than  a  combination  of  its 
component  terms;  it  includes  documentation  and  usage.  For 
example,  “Establish  and  maintain  an  organizational  policy 
for  planning  and  performing  the  organizational  process 
focus  process”  means  that  not  only  must  a  policy  be 
formulated,  but  it  also  must  be  documented  and  it  must  be 
used  throughout  the  organization. 

(See  “objective  evidence.”) 

(See  “senior  manager.”) 

States  of  being  that  must  be  present  before  an  effort  can 
end  successfully. 

CMMI  components  that  explain  what  may  be  done  to  satisfy 
a  required  CMMI  component.  Model  users  can  implement 
the  expected  components  explicitly  or  implement  equivalent 
alternative  practices  to  these  components.  Specific  and 
generic  practices  are  expected  model  components. 

(See  “appraisal  findings.”) 

A  structured  approach  to  evaluating  alternative  solutions 
against  established  criteria  to  determine  a  recommended 
solution  to  address  an  issue. 

(See  “CMMI  Framework.”) 
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Examination  of  a  defined  function  to  identify  all  the 
subfunctions  necessary  to  the  accomplishment  of  that 
function;  identification  of  functional  relationships  and 
interfaces  (internal  and  external)  and  capturing  these  in  a 
functional  architecture;  and  flow  down  of  upper  level 
performance  requirements  and  assignment  of  these 
requirements  to  lower  level  subfunctions.  (See  also 
“functional  architecture.”) 

The  hierarchical  arrangement  of  functions,  their  internal  and 
external  (external  to  the  aggregation  itself)  functional 
interfaces  and  external  physical  interfaces,  their  respective 
functional  and  performance  requirements,  and  their  design 
constraints. 

An  audit  conducted  to  verify  that  the  development  of  a 
configuration  item  has  been  completed  satisfactorily,  that 
the  item  has  achieved  the  performance  and  functional 
characteristics  specified  in  the  functional  or  allocated 
configuration  identification,  and  that  its  operational  and 
support  documents  are  complete  and  satisfactory.  (See 
also:  “configuration  audit,”  “configuration  management,”  and 
“physical  configuration  audit.”) 

A  required  model  component  that  describes  the 
characteristics  that  must  be  present  to  satisfy  the 
institutionalization  of  the  processes  that  implement  a 
process  area.  (See  also  “institutionalization.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  generic  goal.  The  generic 
practices  associated  with  a  generic  goal  describe  the 
activities  that  are  expected  to  result  in  achievement  of  the 
generic  goal  and  contribute  to  the  institutionalization  of  the 
processes  associated  with  a  process  area. 

An  informative  model  component  that  appears  after  a 
generic  practice  to  provide  guidance  on  how  the  generic 
practices  should  be  applied  to  the  process  area. 

A  required  CMMI  component  that  can  be  either  a  generic 
goal  or  a  specific  goal.  When  you  see  the  word  goal  in  a 
CMMI  model,  it  always  refers  to  a  model  component  (e.g., 
generic  goal  and  specific  goal).  (See  also  “generic  goal,” 
“objective,”  and  “specific  goal.”) 
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The  application  of  a  systematic,  disciplined,  and  quantifiable 
approach  to  transform  a  set  of  requirements  representing 
the  collection  of  stakeholder  needs,  expectations,  and 
constraints  using  currently  available  techniques  and 
technology  to  design,  implement,  and  maintain  a  tangible 
product.  (See  also  "software  engineering"  and  "systems 
engineering." 

In  CMMI,  hardware  engineering  represents  all  technical 
fields  (e.g.,  electrical,  mechanical)  that  transform 
requirements  and  ideas  into  tangible  and  producible 
products. 

The  person  or  persons  who  provide  the  policy  and  overall 
guidance  for  the  process,  but  do  not  provide  the  direct  day- 
to-day  monitoring  and  controlling  of  the  process.  Such 
persons  belong  to  a  level  of  management  in  the 
organization  above  the  immediate  level  responsible  for  the 
process  and  can  be  (but  is  not  necessarily)  a  senior 
manager.  (See  also  "senior  manager.") 

A  process  that  is  not  performed  or  is  performed  only 
partially  (also  known  as  capability  level  0).  One  or  more  of 
the  specific  goals  of  the  process  area  are  not  satisfied. 

CMMI  components  that  help  model  users  understand  the 
required  and  expected  components  of  a  model.  These 
components  can  contain  examples,  detailed  explanations, 
or  other  helpful  information.  Subpractices,  notes, 
references,  goal  titles,  practice  titles,  sources,  typical  work 
products,  discipline  amplifications,  and  generic  practice 
elaborations  are  informative  model  components. 

The  ingrained  way  of  doing  business  that  an  organization 
follows  routinely  as  part  of  its  corporate  culture. 

A  systematic  approach  to  product  development  that 
achieves  a  timely  collaboration  of  relevant  stakeholders 
throughout  the  product  life  cycle  to  better  satisfy  customer 
needs. 
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integrated  team 


interface  control 


lead  appraiser 

life-cycle  model 
managed  process 


manager 


maturity  level 


memorandum  of 
agreement 


A  group  of  people  with  complementary  skills  and  expertise 
who  are  committed  to  delivering  specified  work  products  in 
timely  collaboration.  Integrated  team  members  provide  skills 
and  advocacy  appropriate  to  all  phases  of  the  work 
products’  life  and  are  collectively  responsible  for  delivering 
the  work  products  as  specified.  An  integrated  team  should 
include  empowered  representatives  from  organizations, 
disciplines,  and  functions  that  have  a  stake  in  the  success 
of  the  work  products. 

In  configuration  management,  the  process  of  (1)  identifying 
all  functional  and  physical  characteristics  relevant  to  the 
interfacing  of  two  or  more  configuration  items  provided  by 
one  or  more  organizations,  and  (2)  ensuring  that  the 
proposed  changes  to  these  characteristics  are  evaluated 
and  approved  prior  to  implementation.  (See  also 
“configuration  item”  and  “configuration  management.”) 

As  used  in  the  CMMI  Product  Suite,  a  person  who  has 
achieved  recognition  from  an  authorizing  body  to  perform  as 
an  appraisal  team  leader  for  a  particular  appraisal  method. 

A  partitioning  of  the  life  of  a  product  or  project  into  phases. 

A  performed  process  that  is  planned  and  executed  in 
accordance  with  policy;  employs  skilled  people  having 
adequate  resources  to  produce  controlled  outputs;  involves 
relevant  stakeholders;  is  monitored,  controlled,  and 
reviewed;  and  is  evaluated  for  adherence  to  its  process 
description.  (See  also  “performed  process.”) 

In  the  CMMI  Product  Suite,  a  person  who  provides  technical 
and  administrative  direction  and  control  to  those  performing 
tasks  or  activities  within  the  manager’s  area  of 
responsibility.  The  traditional  functions  of  a  manager  include 
planning,  organizing,  directing,  and  controlling  work  within 
an  area  of  responsibility. 

Degree  of  process  improvement  across  a  predefined  set  of 
process  areas  in  which  all  goals  in  the  set  are  attained.  (See 
also  “capability  level”  and  “process  area.”) 

Binding  documents  of  understanding  or  agreements 
between  two  or  more  parties.  Also  known  as  a 
“memorandum  of  understanding.” 
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natural  bounds 


nondevelopmental 
item  (NDI) 


nontechnical 

requirements 


objective 


objective  evidence 


objectively  evaluate 


observation 


The  inherent  process  reflected  by  measures  of  process 
performance,  sometimes  referred  to  as  “voice  of  the 
process.”  Techniques  such  as  control  charts,  confidence 
intervals,  and  prediction  intervals  are  used  to  determine 
whether  the  variation  is  due  to  common  causes  (i.e. ,  the 
process  is  predictable  or  “stable”)  or  is  due  to  some  special 
cause  that  can  and  should  be  identified  and  removed. 

An  item  of  supply  that  was  developed  previous  to  its  current 
use  in  an  acquisition  or  development  process.  Such  an  item 
may  require  minor  modifications  to  meet  the  requirements  of 
its  current  intended  use. 

Contractual  provisions,  commitments,  conditions,  and  terms 
that  affect  how  products  or  services  are  to  be  acquired. 
Examples  include  products  to  be  delivered,  data  rights  for 
delivered  commercial  off-the-shelf  (COTS)  non¬ 
developmental  items  (NDIs),  delivery  dates,  and  milestones 
with  exit  criteria.  Other  nontechnical  requirements  include 
training  requirements,  site  requirements,  and  deployment 
schedules. 

When  used  as  a  noun  in  the  CMMI  Product  Suite,  the  term 
objective  replaces  the  word  goal  as  used  in  its  common 
everyday  sense,  since  the  word  goal  is  reserved  for  use 
when  referring  to  the  CMMI  model  components  called 
specific  goals  and  generic  goals.  (See  also  “goal.”) 

As  used  in  CMMI  appraisal  materials,  qualitative  or 
quantitative  information,  records,  or  statements  of  fact 
pertaining  to  the  characteristics  of  an  item  or  service  or  to 
the  existence  and  implementation  of  a  process  element, 
which  are  based  on  observation,  measurement,  or  test  and 
which  are  verifiable. 

To  review  activities  and  work  products  against  criteria  that 
minimize  subjectivity  and  bias  by  the  reviewer.  An  example 
of  an  objective  evaluation  is  an  audit  against  requirements, 
standards,  or  procedures  by  an  independent  quality 
assurance  function.  (See  also  “audit.”) 

As  used  in  CMMI  appraisal  materials,  a  written  record  that 
represents  the  appraisal  team  members’  understanding  of 
information  either  seen  or  heard  during  the  appraisal  data 
collection  activities.  The  written  record  may  take  the  form  of 
a  statement  or  may  take  alternative  forms  as  long  as  the 
information  content  is  preserved. 
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operational  concept 


operational  scenario 


optimizing  process 


organization 


organizational 

maturity 


organizational 

policy 


organizational 
process  assets 


A  general  description  of  the  way  in  which  an  entity  is  used 
or  operates.  (Also  known  as  “concept  of  operations.”) 

A  description  of  an  imagined  sequence  of  events  that 
includes  the  interaction  of  the  product  with  its  environment 
and  users,  as  well  as  interaction  among  its  product 
components.  Operational  scenarios  are  used  to  evaluate 
the  requirements  and  design  of  the  system  and  to  verify  and 
validate  the  system. 

A  quantitatively  managed  process  that  is  improved  based 
on  an  understanding  of  the  common  causes  of  variation 
inherent  in  the  process.  The  focus  of  an  optimizing  process 
is  on  continually  improving  the  range  of  process 
performance  through  both  incremental  and  innovative 
improvements.  (See  also  “common  cause  of  process 
variation,”  “defined  process,”  and  “quantitatively  managed 
process.”) 

An  administrative  structure  in  which  people  collectively 
manage  one  or  more  projects  as  a  whole,  and  whose 
projects  share  a  senior  manager  and  operate  under  the 
same  policies.  However,  the  word  organization  as  used 
throughout  CMMI  models  can  also  apply  to  one  person  who 
performs  a  function  in  a  small  organization  that  might  be 
performed  by  a  group  of  people  in  a  large  organization. 

(See  also  “enterprise”  and  “organizational  unit.”) 

The  extent  to  which  an  organization  has  explicitly  and 
consistently  deployed  processes  that  are  documented, 
managed,  measured,  controlled,  and  continually  improved. 
Organizational  maturity  may  be  measured  via  appraisals. 

A  guiding  principle  typically  established  by  senior 
management  that  is  adopted  by  an  organization  to  influence 
and  determine  decisions. 

Artifacts  that  relate  to  describing,  implementing,  and 
improving  processes  (e.g.,  policies,  measurements,  process 
descriptions,  and  process  implementation  support  tools). 
The  term  process  assets  is  used  to  indicate  that  these 
artifacts  are  developed  or  acquired  to  meet  the  business 
objectives  of  the  organization,  and  they  represent 
investments  by  the  organization  that  are  expected  to 
provide  current  and  future  business  value.  (See  also 
“process  asset  library.”) 
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organizational  unit 


organization's 
business  objectives 


organization's 

measurement 

repository 


organization's 
process  asset 
library 


The  part  of  an  organization  that  is  the  subject  of  an 
appraisal;  also  known  as  the  organizational  scope  of  the 
appraisal. 

An  organizational  unit  deploys  one  or  more  processes  that 
have  a  coherent  process  context  and  operates  within  a 
coherent  set  of  business  objectives.  An  organizational  unit 
is  typically  part  of  a  larger  organization,  although  in  a  small 
organization,  the  organizational  unit  may  be  the  whole 
organization. 

Senior  management  developed  strategies  designed  to 
ensure  an  organization’s  continued  existence  and  enhance 
its  profitability,  market  share,  and  other  factors  influencing 
the  organization’s  success.  (See  also  “quality  and  process- 
performance  objectives”  and  “quantitative  objective.”) 

Such  objectives  may  include  reducing  the  number  of 
change  requests  during  a  system’s  integration  phase, 
reducing  development  cycle  time,  increasing  the  number  of 
errors  found  in  a  product’s  first  or  second  phase  of 
development,  and  reducing  the  number  of  customer- 
reported  defects,  when  applied  to  systems  engineering 
activities. 

A  repository  used  to  collect  and  make  available 
measurement  data  on  processes  and  work  products, 
particularly  as  they  relate  to  the  organization’s  set  of 
standard  processes.  This  repository  contains  or  references 
actual  measurement  data  and  related  information  needed  to 
understand  and  analyze  the  measurement  data. 

A  library  of  information  used  to  store  and  make  available 
process  assets  that  are  useful  to  those  who  are  defining, 
implementing,  and  managing  processes  in  the  organization. 
This  library  contains  process  assets  that  include  process- 
related  documentation  such  as  policies,  defined  processes, 
checklists,  lessons-learned  documents,  templates, 
standards,  procedures,  plans,  and  training  materials. 
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organization's  set  of 
standard  processes 


outsourcing 
peer  review 

performance 

parameters 

performed  process 

physical 

configuration  audit 

planned  process 

policy 

process 


A  collection  of  definitions  of  the  processes  that  guide 
activities  in  an  organization.  These  process  descriptions 
cover  the  fundamental  process  elements  (and  their 
relationships  to  each  other,  such  as  ordering  and  interfaces) 
that  must  be  incorporated  into  the  defined  processes  that 
are  implemented  in  projects  across  the  organization.  A 
standard  process  enables  consistent  development  and 
maintenance  activities  across  the  organization  and  is 
essential  for  long-term  stability  and  improvement.  (See  also 
“defined  process”  and  “process  element.”) 

(See  "acquisition.") 

The  review  of  work  products  performed  by  peers  during 
development  of  the  work  products  to  identify  defects  for 
removal.  The  term  peer  review  is  used  in  the  CMMI  Product 
Suite  instead  of  the  term  work  product  inspection.  (See  also 
"work  product.") 

The  measures  of  effectiveness  and  other  key  measures 
used  to  guide  and  control  progressive  development. 

A  process  that  accomplishes  the  needed  work  to  produce 
work  products.  The  specific  goals  of  the  process  area  are 
satisfied. 

An  audit  conducted  to  verify  that  a  configuration  item,  as 
built,  conforms  to  the  technical  documentation  that  defines 
it.  (See  also:  “configuration  audit,”  “configuration 
management,”  and  “functional  configuration  audit.”) 

A  process  that  is  documented  both  by  a  description  and  a 
plan.  The  description  and  plan  should  be  coordinated,  and 
the  plan  should  include  standards,  requirements,  objectives, 
resources,  assignments,  and  so  on. 

(See  “organizational  policy.”) 

In  the  CMMI  Product  Suite,  activities  that  can  be  recognized 
as  implementations  of  practices  in  a  CMMI  model.  These 
activities  can  be  mapped  to  one  or  more  practices  in  CMMI 
process  areas  to  allow  a  model  to  be  useful  for  process 
improvement  and  process  appraisal.  (See  also  “process 
area,”  “subprocess,”  and  “process  element.”) 

There  is  a  special  use  of  the  phrase  the  process  in  the 
statements  and  descriptions  of  the  generic  goals  and 
generic  practices.  ’’The  process,”  as  used  in  Part  Two  is  the 
process  or  processes  that  implement  the  process  area. 


386 


Glossary 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


process  action  plan 


process  action  team 


process  and 

technology 

improvements 

process  architecture 


process  area 

process  asset 

process  asset 
library 

process  attribute 
process  capability 
process  context 


A  plan,  usually  resulting  from  appraisals,  that  documents 
how  specific  improvements  targeting  the  weaknesses 
uncovered  by  an  appraisal  will  be  implemented. 

A  team  that  has  the  responsibility  to  develop  and  implement 
process  improvement  activities  for  an  organization  as 
documented  in  a  process  action  plan. 

Incremental  and  innovative  improvements  to  processes  and 
also  to  process  or  product  technologies. 

The  ordering,  interfaces,  interdependencies,  and  other 
relationships  among  the  process  elements  in  a  standard 
process.  Process  architecture  also  describes  the  interfaces, 
interdependencies,  and  other  relationships  between  process 
elements  and  external  processes  (e.g.,  contract 
management). 

A  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfy  a  set  of  goals  considered 
important  for  making  improvement  in  that  area.  All  CMMI 
process  areas  are  common  to  both  continuous  and  staged 
representations. 

Anything  that  the  organization  considers  useful  in  attaining 
the  goals  of  a  process  area.  (See  also  “organizational 
process  assets.”) 

A  collection  of  process  asset  holdings  that  can  be  used  by 
an  organization  or  project.  (See  also  “organization’s  process 
asset  library.”) 

A  measurable  characteristic  of  process  capability  applicable 
to  any  process. 

The  range  of  expected  results  that  can  be  achieved  by 
following  a  process. 

The  set  of  factors,  documented  in  the  appraisal  input,  that 
influences  the  judgment  and  comparability  of  appraisal 
ratings. 

These  include,  but  are  not  limited  to,  (a)  the  size  of  the 
organizational  unit  to  be  appraised;  (b)  the  demographics  of 
the  organizational  unit;  (c)  the  application  domain  of  the 
products  or  services;  (d)  the  size,  criticality,  and  complexity 
of  the  products  or  services;  and  (e)  the  quality 
characteristics  of  the  products  or  services. 
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process  definition 


process  description 


process  element 


process  group 


process 

improvement 


process- 

improvement 

objectives 


process- 

improvement  plan 


The  act  of  defining  and  describing  a  process.  The  result  of 
process  definition  is  a  process  description.  (See  also 
“process  description.”) 

A  documented  expression  of  a  set  of  activities  performed  to 
achieve  a  given  purpose  that  provides  an  operational 
definition  of  the  major  components  of  a  process.  The 
documentation  specifies,  in  a  complete,  precise,  and 
verifiable  manner,  the  requirements,  design,  behavior,  or 
other  characteristics  of  a  process.  It  also  may  include 
procedures  for  determining  whether  these  provisions  have 
been  satisfied.  Process  descriptions  can  be  found  at  the 
activity,  project,  or  organizational  level. 

The  fundamental  unit  of  a  process.  A  process  can  be 
defined  in  terms  of  subprocesses  and/or  process  elements. 
A  subprocess  can  be  further  decomposed  into 
subprocesses  and/or  process  elements;  a  process  element 
cannot.  (See  also  “process”  and  “subprocess.”) 

Each  process  element  covers  a  closely  related  set  of 
activities  (e.g.,  estimating  element,  peer  review  element). 
Process  elements  can  be  portrayed  using  templates  to  be 
completed,  abstractions  to  be  refined,  or  descriptions  to  be 
modified  or  used.  A  process  element  can  be  an  activity  or 
task. 

A  collection  of  specialists  who  facilitate  the  definition, 
maintenance,  and  improvement  of  the  process(es)  used  by 
the  organization. 

A  program  of  activities  designed  to  improve  the 
performance  and  maturity  of  the  organization’s  processes, 
and  the  results  of  such  a  program. 

A  set  of  target  characteristics  established  to  guide  the  effort 
to  improve  an  existing  process  in  a  specific,  measurable 
way  either  in  terms  of  resultant  product  characteristics  (e.g., 
quality,  performance,  conformance  to  standards)  or  in  the 
way  in  which  the  process  is  executed  (e.g.,  elimination  of 
redundant  process  steps,  combination  of  process  steps, 
improvement  of  cycle  time).  (See  also  “organization’s 
business  objectives”  and  “quantitative  objective.”) 

A  plan  for  achieving  organizational  process-improvement 
objectives  based  on  a  thorough  understanding  of  the  current 
strengths  and  weaknesses  of  the  organization’s  processes 
and  process  assets. 
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process 

measurement 


process  owner 


process 

performance 


process 

performance 

baseline 


process 

performance  model 


process  tailoring 


product 


The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for 
the  purpose  of  characterizing  and  understanding  the 
process. 

The  person  (or  team)  responsible  for  defining  and 
maintaining  a  process.  At  the  organizational  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  a  standard  process;  at  the  project  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  the  defined  process.  A  process  may  therefore 
have  multiple  owners  at  different  levels  of  responsibility. 

(See  also  “defined  process"  and  “standard  process.”) 

A  measure  of  actual  results  achieved  by  following  a 
process.  It  is  characterized  by  both  process  measures  (e.g., 
effort,  cycle  time,  and  defect  removal  efficiency)  and  product 
measures  (e.g.,  reliability,  defect  density,  and  response 
time). 

A  documented  characterization  of  the  actual  results 
achieved  by  following  a  process,  which  is  used  as  a 
benchmark  for  comparing  actual  process  performance 
against  expected  process  performance.  (See  also  “process 
performance.”) 

A  description  of  the  relationships  among  attributes  of  a 
process  and  its  work  products  that  are  developed  from 
historical  process  performance  data  and  calibrated  using 
collected  process  and  product  measures  from  the  project 
and  that  are  used  to  predict  results  to  be  achieved  by 
following  a  process. 

Making,  altering,  or  adapting  a  process  description  for  a 
particular  end.  For  example,  a  project  tailors  its  defined 
process  from  the  organization’s  set  of  standard  processes 
to  meet  the  objectives,  constraints,  and  environment  of  the 
project.  (See  also  “defined  process,”  “organization’s  set  of 
standard  processes,”  and  “process  description.”) 

In  the  CMMI  Product  Suite,  a  work  product  that  is  intended 
for  delivery  to  a  customer  or  end  user.  The  form  of  a  product 
can  vary  in  different  contexts.  (See  also  “customer,” 

“product  component,”  and  “work  product.”) 
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product  baseline 


product  component 

product-component 

requirements 

product  life  cycle 


product  line 


product-related  life- 
cycle  processes 


product 

requirements 


product  suite 


In  configuration  management,  the  initial  approved  technical 
data  package  (including,  for  software,  the  source  code 
listing)  defining  a  configuration  item  during  the  production, 
operation,  maintenance,  and  logistic  support  of  its  life  cycle. 
(See  also  “configuration  item”  and  “configuration 
management.”) 

In  the  CMMI  Product  Suite,  a  work  product  that  is  a  lower 
level  component  of  the  product.  Product  components  are 
integrated  to  produce  the  product.  There  may  be  multiple 
levels  of  product  components.  (See  also  “product”  and 
“work  product.”) 

A  complete  specification  of  a  product  component,  including 
fit,  form,  function,  performance,  and  any  other  requirement. 

The  period  of  time,  consisting  of  phases,  that  begins  when  a 
product  is  conceived  and  ends  when  the  product  is  no 
longer  available  for  use.  Since  an  organization  may  be 
producing  multiple  products  for  multiple  customers,  one 
description  of  a  product  life  cycle  may  not  be  adequate. 
Therefore,  the  organization  may  define  a  set  of  approved 
product  life-cycle  models.  These  models  are  typically  found 
in  published  literature  and  are  likely  to  be  tailored  for  use  in 
an  organization. 

A  product  life  cycle  could  consist  of  the  following  phases:  (1) 
concept/vision,  (2)  feasibility,  (3)  design/development,  (4) 
production,  and  (5)  phase  out. 

A  group  of  products  sharing  a  common,  managed  set  of 
features  that  satisfy  specific  needs  of  a  selected  market  or 
mission. 

Processes  associated  with  a  product  throughout  one  or 
more  phases  of  its  life  (e.g.,  from  conception  through 
disposal),  such  as  the  manufacturing  and  support 
processes. 

A  refinement  of  the  customer  requirements  into  the 
developers’  language,  making  implicit  requirements  into 
explicit  derived  requirements.  (See  also  “derived 
requirements”  and  “product-component  requirements.”) 

The  developer  uses  the  product  requirements  to  guide  the 
design  and  building  of  the  product. 

(See  “CMMI  Product  Suite.”) 
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project 


project  manager 


project  plan 


project  progress 
and  performance 


project's  defined 
process 


(See  “achievement  profile”  and  “target  profile.”) 

(1)  A  project.  (2)  A  collection  of  related  projects  and  the 
infrastructure  that  supports  them,  including  objectives, 
methods,  activities,  plans,  and  success  measures.  (See 
also  “project.”) 

In  the  CMMI  Product  Suite,  a  managed  set  of  interrelated 
resources  that  delivers  one  or  more  products  to  a  customer 
or  end  user.  A  project  has  a  definite  beginning  and  end  and 
typically  operates  according  to  a  plan.  Such  a  plan  is 
frequently  documented  and  specifies  the  product  to  be 
delivered  or  implemented,  the  resources  and  funds  to  be 
used,  the  work  to  be  done,  and  a  schedule  for  doing  the 
work.  A  project  can  be  composed  of  projects. 

In  the  CMMI  Product  Suite,  the  person  responsible  for 
planning,  directing,  controlling,  structuring,  and  motivating 
the  project.  The  project  manager  is  responsible  for 
satisfying  the  customer. 

A  plan  that  provides  the  basis  for  performing  and  controlling 
the  project’s  activities,  which  addresses  the  commitments  to 
the  project’s  customer. 

Project  planning  includes  estimating  the  attributes  of  the 
work  products  and  tasks,  determining  the  resources 
needed,  negotiating  commitments,  producing  a  schedule, 
and  identifying  and  analyzing  project  risks.  Iterating  through 
these  activities  may  be  necessary  to  establish  the  project 
plan. 

What  a  project  achieves  with  respect  to  implementing 
project  plans,  including  effort,  cost,  schedule,  and  technical 
performance. 

The  integrated  and  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes.  (See  also  “defined 
process.”) 


Glossary 


391 


Adapting  CMMI  for  Acquisition  Organizations:  A  Preliminary  Report 


prototype 


quality 


quality  and  process- 

performance 

objectives 


quality  assurance 


quality  control 


quantitative 

objective 


quantitatively 
managed  process 


A  preliminary  type,  form,  or  instance  of  a  product  or  product 
component  that  serves  as  a  model  for  later  stages  or  for  the 
final,  complete  version  of  the  product.  This  model  (e.g., 
physical,  electronic,  digital,  analytical)  can  be  used  for  the 
following  (and  other)  purposes: 

•  assessing  the  feasibility  of  a  new  or  unfamiliar 
technology 

•  assessing  or  mitigating  technical  risk 

•  validating  requirements 

•  demonstrating  critical  features 

•  qualifying  a  product 

•  qualifying  a  process 

•  characterizing  performance  or  product  features 

•  elucidating  physical  principles 

The  ability  of  a  set  of  inherent  characteristics  of  a  product, 
product  component,  or  process  to  fulfill  requirements  of 
customers. 

Objectives  and  requirements  for  product  quality,  service 
quality,  and  process  performance.  Process-performance 
objectives  include  product  quality;  however,  to  emphasize 
the  importance  of  product  quality  in  the  CMMI  Product 
Suite,  the  phrase  quality  and  process-performance 
objectives  is  used  rather  than  just  process-performance 
objectives. 

A  planned  and  systematic  means  for  assuring  management 
that  the  defined  standards,  practices,  procedures,  and 
methods  of  the  process  are  applied. 

The  operational  techniques  and  activities  that  are  used  to 
fulfill  requirements  for  quality.  (See  also  “quality 
assurance.”) 

Desired  target  value  expressed  as  quantitative  measures. 
(See  also  “process-improvement  objectives"  and  “quality 
and  process-performance  objectives.”) 

A  defined  process  that  is  controlled  using  statistical  and 
other  quantitative  techniques.  The  product  quality,  service 
quality,  and  process  performance  attributes  are  measurable 
and  controlled  throughout  the  project.  (See  also  “defined 
process,”  “optimizing  process,”  and  “statistically  managed 
process.”) 
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(See  “appraisal  rating.”) 

An  informative  model  component  that  points  to  additional  or 
more  detailed  information  in  related  process  areas. 

A  model  that  is  used  as  a  benchmark  for  measuring  some 
attribute. 

A  stakeholder  that  is  identified  for  involvement  in  specified 
activities  and  is  included  in  a  plan.  (See  also  “stakeholder.”) 

The  organization,  use,  and  presentation  of  a  CMM’s 
components.  Overall,  two  types  of  approaches  to  presenting 
best  practices  are  evident:  the  staged  representation  and 
the  continuous  representation. 

CMMI  components  that  are  essential  to  achieving  process 
improvement  in  a  given  process  area.  These  components 
are  used  in  appraisals  to  determine  process  capability. 
Specific  goals  and  generic  goals  are  required  model 
components. 

(1 )  A  condition  or  capability  needed  by  a  user  to  solve  a 
problem  or  achieve  an  objective.  (2)  A  condition  or 
capability  that  must  be  met  or  possessed  by  a  product  or 
product  component  to  satisfy  a  contract,  standard, 
specification,  or  other  formally  imposed  documents.  (3)  A 
documented  representation  of  a  condition  or  capability  as  in 

(1)  °r  (2). 

The  determination  of  product-specific  performance  and 
functional  characteristics  based  on  analyses  of  customer 
needs,  expectations,  and  constraints;  operational  concept; 
projected  utilization  environments  for  people,  products,  and 
processes;  and  measures  of  effectiveness. 

Using  systematic  techniques,  such  as  prototypes  and 
structured  surveys,  to  proactively  identify  and  document 
customer  and  end-user  needs. 

The  management  of  all  requirements  received  by  or 
generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements 
levied  on  the  project  by  the  organization. 

A  discernable  association  between  requirements  and 
related  requirements,  implementations,  and  verifications. 
(See  also  “bidirectional  traceability”  and  “traceability.”) 
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risk  management 


risk  management 
strategy 
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service 


The  ratio  of  revenue  from  output  (product)  to  production 
costs,  which  determines  whether  an  organization  benefits 
from  performing  an  action  to  produce  something. 

The  evaluation,  classification,  and  prioritization  of  risks. 

An  organized,  thorough  approach  to  seek  out  probable  or 
realistic  risks  in  achieving  objectives. 

An  organized,  analytic  process  to  identify  what  might  cause 
harm  or  loss  (identify  risks);  to  assess  and  quantify  the 
identified  risks;  and  to  develop  and,  if  needed,  implement  an 
appropriate  approach  to  prevent  or  handle  causes  of  risk 
that  could  result  in  significant  harm  or  loss. 

An  organized,  technical  approach  to  identify  what  might 
cause  harm  or  loss  (identify  risks);  to  assess  and  quantify 
the  identified  risks;  and  to  develop  and,  if  needed, 
implement  an  appropriate  approach  to  prevent  or  handle 
causes  of  risk  that  could  result  in  significant  harm  or  loss. 
Typically,  risk  management  is  performed  for  project, 
organization,  or  product  developing  organizational  units. 

A  source  of  a  defect  such  that  if  it  is  removed,  the  defect  is 
decreased  or  removed. 

In  the  CMMI  Product  Suite,  a  management  role  at  a  high 
enough  level  in  an  organization  that  the  primary  focus  of  the 
person  filling  the  role  is  the  long-term  vitality  of  the 
organization  rather  than  short-term  project  and  contractual 
concerns  and  pressures.  A  senior  manager  has  authority  to 
direct  the  allocation  or  reallocation  of  resources  in  support  of 
organizational  process  improvement  effectiveness.  (See 
also  "higher  level  management.") 

A  senior  manager  can  be  any  manager  who  satisfies  this 
description,  including  the  head  of  the  organization. 

Synonyms  for  “senior  manager”  include  “executive”  and 
“top-level  manager.”  However,  to  ensure  consistency  and 
usability,  these  synonyms  are  not  used  in  CMMI  models. 

In  the  CMMI  Product  Suite,  a  service  is  a  product  whose 
primary  value  is  delivered  to  a  customer  or  end  user  in  a 
form  that  is  intangible,  non-storable,  and  is  dependent  on 
the  direct  application  of  labor.  (See  also  "product," 
"customer,"  and  "work  product.") 
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engineering 

solicitation 

solicitation  package 


special  cause  of 
process  variation 


specific  goal 


specific  practice 


stable  process 


A  common  understanding  of  guiding  principles  including 
mission,  objectives,  expected  behavior,  values,  and  final 
outcomes,  which  are  developed  and  used  by  a  project. 

(1)The  application  of  a  systematic,  disciplined,  quantifiable 
approach  to  the  development,  operation,  and  maintenance 
of  software.  (2)  The  study  of  approaches  as  in  (1).  (See  also 
"hardware  engineering,"  and  "systems  engineering.") 

The  process  of  preparing  a  package  to  be  used  in  selecting 
a  supplier  (contractor).  (See  also  “solicitation  package.”) 

A  formal  document  delineating  technical  and  nontechnical 
requirements  that  is  used  to  request  offers  on  invitations  for 
bid  (bids)  and  requests  for  proposal  (proposals),  or  to 
request  statements  of  capabilities  and  price  quotations 
(quotes).  It  is  otherwise  used  as  a  basis  for  selecting  a 
supply  source  or  sources  to  provide  products  or  services. 

A  cause  of  a  defect  that  is  specific  to  some  transient 
circumstance  and  not  an  inherent  part  of  a  process.  (See 
also  “common  cause  of  process  variation.”) 

A  required  model  component  that  describes  the  unique 
characteristics  that  must  be  present  to  satisfy  the  process 
area.  (See  also  “capability  level,”  “generic  goal,” 
“organization’s  business  objectives,"  and  “process  area.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  specific  goal.  The  specific 
practices  describe  the  activities  expected  to  result  in 
achievement  of  the  specific  goals  of  a  process  area.  (See 
also  “process  area”  and  “specific  goal.”) 

In  the  continuous  representation,  every  specific  practice  is 
associated  with  a  capability  level.  The  staged  representation 
does  not  recognize  capability  levels,  so  all  specific  practices 
are  treated  equally. 

The  state  in  which  all  special  causes  of  process  variation 
have  been  removed  and  prevented  from  recurring  so  that 
only  the  common  causes  of  process  variation  of  the  process 
remain.  (See  also  “capable  process,"  “common  cause  of 
process  variation,”  “special  cause  of  process  variation,” 
“standard  process,”  and  “statistically  managed  process.”) 
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representation 
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standard  process 


statement  of  work 


statistical 

predictability 

statistical  process 
control 


statistical 
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A  model  structure  wherein  attaining  the  goals  of  a  set  of 
process  areas  establishes  a  maturity  level;  each  level  builds 
a  foundation  for  subsequent  levels.  (See  also  “maturity 
level”  and  “process  area.”) 

In  the  CMMI  Product  Suite,  a  group  or  individual  that  is 
affected  by  or  is  in  some  way  accountable  for  the  outcome 
of  an  undertaking.  Stakeholders  may  include  project 
members,  suppliers,  customers,  end  users,  and  others. 

(See  also  “customer”  and  “relevant  stakeholder.”) 

When  you  see  the  word  standard  used  as  a  noun  in  a  CMMI 
model,  it  refers  to  the  formal  mandatory  requirements 
developed  and  used  to  prescribe  consistent  approaches  to 
development  (e.g.,  ISO/IEC  standards,  IEEE  standards, 
organizational  standards).  Instead  of  using  standard  in  its 
common  everyday  sense,  we  chose  another  term  that 
means  the  same  thing  (e.g.,  typical,  traditional,  usual,  or 
customary). 

An  operational  definition  of  the  basic  process  that  guides 
the  establishment  of  a  common  process  in  an  organization. 

A  standard  process  describes  the  fundamental  process 
elements  that  are  expected  to  be  incorporated  into  any 
defined  process.  It  also  describes  the  relationships  (e.g., 
ordering  and  interfaces)  among  these  process  elements. 
(See  also  “defined  process.”) 

A  description  of  contracted  work  required  to  complete  a 
project. 

The  performance  of  a  quantitative  process  that  is  controlled 
using  statistical  and  other  quantitative  techniques. 

Statistically  based  analysis  of  a  process  and  measurements 
of  process  performance,  which  will  identify  common  and 
special  causes  of  variation  in  the  process  performance,  and 
maintain  process  performance  within  limits.  (See  also 
“common  cause  of  process  variation,”  “special  cause  of 
process  variation,”  and  “statistically  managed  process.”) 

An  analytic  technique  that  employs  statistical  methods  (e.g., 
statistical  process  control,  confidence  intervals,  and 
prediction  intervals). 
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subprocess 


supplier 


sustainment 


systems 

engineering 


A  process  that  is  managed  by  a  statistically  based 
technique  in  which  processes  are  analyzed,  special  causes 
of  process  variation  are  identified,  and  performance  is 
contained  within  well-defined  limits.  (See  also  “capable 
process,”  “special  cause  of  process  variation,”  “stable 
process,”  “standard  process,”  and  “statistical  process 
control.”) 

As  used  in  CMMI  appraisal  materials,  an  exemplary  or 
noteworthy  implementation  of  a  CMMI  model  practice. 

An  informative  model  component  that  provides  guidance  for 
interpreting  and  implementing  specific  or  generic  practices. 
Subpractices  may  be  worded  as  if  prescriptive,  but  are 
actually  meant  only  to  provide  ideas  that  may  be  useful  for 
process  improvement. 

A  process  that  is  part  of  a  larger  process.  A  subprocess  can 
be  decomposed  into  subprocesses  and/or  process 
elements.  (See  also  “process,”  “process  description,”  and 
“process  element.”) 

(1)  An  entity  delivering  products  or  performing  services 
being  acquired.  (2)  An  individual,  partnership,  company, 
corporation,  association,  or  other  service  having  an 
agreement  (contract)  with  an  acquirer  for  the  design, 
development,  manufacture,  maintenance,  modification,  or 
supply  of  items  under  the  terms  of  an  agreement  (contract). 

The  processes  used  to  ensure  that  a  product  can  be  utilized 
operationally  by  its  end  users  or  customers.  Sustainment 
ensures  that  maintenance  is  done  such  that  the  product  is  in 
an  operable  condition  whether  or  not  the  product  is  in  use 
by  customers  or  end  users. 

The  interdisciplinary  approach  governing  the  total  technical 
and  managerial  effort  required  to  transform  a  set  of 
customer  needs,  expectations,  and  constraints  into  a 
product  solution  and  to  support  that  solution  throughout  the 
product’s  life.  (See  also  “hardware  engineering”  and 
“software  engineering.”) 

This  includes  the  definition  of  technical  performance 
measures,  the  integration  of  engineering  specialties  toward 
the  establishment  of  a  product  architecture,  and  the 
definition  of  supporting  life-cycle  processes  that  balance 
cost,  performance,  and  schedule  objectives. 
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tailoring  guidelines 
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target  staging 


technical  data 
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Tailoring  a  process  makes,  alters,  or  adapts  the  process 
description  for  a  particular  end.  For  example,  a  project 
establishes  its  defined  process  by  tailoring  from  the 
organization’s  set  of  standard  processes  to  meet  the 
objectives,  constraints,  and  environment  of  the  project. 

Organizational  guidelines  that  enable  projects,  groups,  and 
organizational  functions  to  appropriately  adapt  standard 
processes  for  their  use.  The  organization’s  set  of  standard 
processes  is  described  at  a  general  level  that  may  not  be 
directly  usable  to  perform  a  process. 

Tailoring  guidelines  aid  those  who  establish  the  defined 
processes  for  projects.  Tailoring  guidelines  cover  (1) 
selecting  a  standard  process,  (2)  selecting  an  approved  life- 
cycle  model,  and  (3)  tailoring  the  selected  standard  process 
and  life-cycle  model  to  fit  project  needs.  Tailoring  guidelines 
describe  what  can  and  cannot  be  modified  and  identify 
process  components  that  are  candidates  for  modification. 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  an 
objective  for  process  improvement.  (See  also  “achievement 
profile”  and  “capability  level  profile.”) 

In  the  continuous  representation,  a  sequence  of  target 
profiles  that  describes  the  path  of  process  improvement  to 
be  followed  by  the  organization.  (See  also  “achievement 
profile,”  “capability  level  profile,”  and  “target  profile.”) 

A  collection  of  items  that  can  include  the  following  if  such 
information  is  appropriate  to  the  type  of  product  and  product 
component  (e.g.,  material  and  manufacturing  requirements 
may  not  be  useful  for  product  components  associated  with 
software  services  or  processes): 

•  product  architecture  description 

•  allocated  requirements 

•  product-component  descriptions 

•  product-related  life-cycle  process  descriptions  if  not 
described  as  separate  -product  components 

•  key  product  characteristics 

•  required  physical  characteristics  and  constraints 

•  interface  requirements 

•  materials  requirements  (bills  of  material  and  material 
characteristics) 
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test  procedure 
traceability 


trade  study 


training 


typical  work  product 


unit  testing 


validation 


verification 


•  fabrication  and  manufacturing  requirements  (for  both 
the  original  equipment  manufacturer  and  field  support) 

•  verification  criteria  used  to  ensure  requirements  have 
been  achieved 

•  conditions  of  use  (environments)  and  operating/usage 
scenarios,  modes  and  states  for  operations,  support, 
training,  manufacturing,  disposal,  and  verifications 
throughout  the  life  of  the  product 

•  rationale  for  decisions  and  characteristics  (e.g., 
requirements,  requirement  allocations,  design  choices) 

Properties  (attributes)  of  products  or  services  to  be  acquired 
or  developed. 

Detailed  instructions  for  the  setup,  execution,  and 
evaluation  of  results  for  a  given  test. 

A  discernable  association  among  two  or  more  logical 
entities  such  as  requirements,  system  elements, 
verifications,  or  tasks.  (See  also  “bidirectional  traceability” 
and  “requirements  traceability.”) 

An  evaluation  of  alternatives,  based  on  criteria  and 
systematic  analysis,  to  select  the  best  alternative  for 
attaining  determined  objectives. 

Formal  and  informal  learning  options,  which  may  include  in- 
class  training,  informal  mentoring,  Web-based  training, 
guided  self-study,  and  formalized  on-the-job  training 
programs.  The  learning  options  selected  for  each  situation 
are  based  on  an  assessment  of  the  need  for  training  and 
the  performance  gap  to  be  addressed. 

An  informative  model  component  that  provides  sample 
outputs  from  a  specific  practice.  These  examples  are  called 
typical  work  products  because  there  are  often  other  work 
products  that  are  just  as  effective,  but  are  not  listed. 

Testing  of  individual  hardware  or  software  units  or  groups  of 
related  units.  (See  also  “acceptance  testing.”) 

Confirmation  that  the  product,  as  provided  (or  as  it  will  be 
provided),  will  fulfill  its  intended  use.  In  other  words, 
validation  ensures  that  “you  built  the  right  thing.”  (See  also 
“verification.”) 

Confirmation  that  work  products  properly  reflect  the 
requirements  specified  for  them.  In  other  words,  verification 
ensures  that  “you  built  it  right.”  (See  also  “validation.”) 
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The  establishment  and  maintenance  of  baselines  and  the 
identification  of  changes  to  baselines  that  make  it  possible 
to  return  to  the  previous  baseline. 

As  used  in  CMMI  appraisal  materials,  the  ineffective,  or  lack 
of,  implementation  of  one  or  more  CMMI  model  practices. 

An  arrangement  of  work  elements  and  their  relationship  to 
each  other  and  to  the  end  product. 

In  the  CMMI  Product  Suite,  a  useful  result  of  a  process.  This 
can  include  files,  documents,  products,  parts  of  the  product, 
services,  process  descriptions,  specifications,  and  invoices. 
A  key  distinction  between  a  work  product  and  a  product 
component  is  that  a  work  product  is  not  necessarily  part  of 
the  end  product.  (See  also  “product”  and  “product 
component.”) 

In  CMMI  models,  you  will  see  the  phrase  work  products  and 
services.  Even  though  the  definition  of  work  product 
includes  services,  this  phrase  is  used  to  emphasize  the 
inclusion  of  services  in  the  discussion. 

Characteristics  of  products,  services,  and  project  tasks  used 
to  help  in  estimating  project  work.  These  characteristics 
include  items  such  as  size,  complexity,  weight,  form,  fit,  and 
function.  They  are  typically  used  as  one  input  to  deriving 
other  project  and  resource  estimates  (e.g.,  effort,  cost,  and 
schedule). 
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